Wazuh malware detection with YARA and rootcheck

How Wazuh malware detection fits your endpoint security program

Wazuh malware detection gives a security team a way to check whether endpoints hold malware, using rootcheck, YARA scans triggered by file changes, hash lists, VirusTotal lookups, and the ingestion of ClamAV and Windows Defender logs. It suits teams that want these checks to run in infrastructure they control rather than in a vendor's cloud. The features are built into the Wazuh platform, so the decision is less about buying a separate scanner and more about whether your team can operate, tune and trust the detections that Wazuh produces.

Wazuh agents installed on Linux, Windows and macOS endpoints collect data and report it to the Wazuh server. The server applies decoders to normalize that data and then runs rules against it, and alerts are stored in the Wazuh indexer and viewed in the Wazuh dashboard. Malware detection depends on this chain working end to end. An endpoint without a healthy agent produces no rootcheck or file-integrity events, and a rule that was never tuned for your environment will either flood analysts with noise or stay silent about a real finding.

That is why agent coverage and rule tuning should be treated as part of the malware program, not as setup work to finish later. Before relying on these detections, inventory which endpoints run agents, which operating systems and builds they use, and whether the directories you care about, such as user download folders, temporary paths and web roots, are actually monitored. Then decide who owns rule changes, how false positives are reviewed, and how alerts from YARA, hash checks and antivirus logs are routed to the people who respond to them.

Be aware of the limits. Wazuh detects malware through the signals it receives, so it complements rather than replaces an endpoint protection product that blocks execution. Confirm with your own tests which scenarios your deployment actually alerts on.

The exact options, including which rootcheck checks, YARA integration settings, VirusTotal configuration and ClamAV or Windows Defender log handling are available, depend on the Wazuh 4.14 line you run. Patch releases in this line change behavior and fixes over time, so check each setting against the current Wazuh documentation for your exact version before you build the detection workflow around it.

Choosing between rootcheck, YARA, hash lists and VirusTotal lookups

This table compares the four Wazuh detection methods covered here and the two imported antivirus log sources, showing what each inspects, what triggers it, what it needs and when it fits. Read the rows as a set, because most teams combine a local method with a targeted external one. The VirusTotal row carries a data governance decision, since file hashes or files leave your environment.

Method	Inspects and triggers	Needs	Fits when
Rootcheck	Checks endpoints for rootkit indicators, suspicious files, hidden processes and port anomalies. Runs on a scheduled interval.	Signature databases shipped with the agent and server. Keep Wazuh updated and confirm current contents.	You want a broad baseline on every agent and accept that it catches known patterns only.
YARA scanning on file changes	Scans new or modified files after file integrity monitoring raises an event. Triggered by changes, not a schedule.	YARA rule sets you write or source and maintain, plus the active response configuration.	Directories where untrusted processes write files, such as web roots or upload folders.
Hash lists	Compares file hashes against lists of known-bad values loaded as CDB lists. Triggered when a rule matches a file or process event.	Hash lists you curate, with a process to add and retire entries.	You hold known-bad indicators from incident work or a feed your licence permits you to use.
VirusTotal lookups	Sends file hashes, or files, to the VirusTotal service and reads its verdicts. Triggered by matched file events.	A VirusTotal API key, outbound network access and a data governance decision.	Data governance has approved sending hashes or files outside the organization for this purpose.
ClamAV logs	Ingests alerts from ClamAV scans run elsewhere on the host or gateway. Triggered when ClamAV writes to a log Wazuh collects.	A running ClamAV installation, a log collection setup and a decoder check against your log format.	You already run ClamAV and want its findings in the same alert queue.
Windows Defender logs	Collects Microsoft Defender detection and remediation events from Windows event channels. Triggered when Defender writes events.	Defender active on endpoints and the event channel collected by the agent.	Windows fleets already run Defender as the antivirus product and you want its events correlated.

What rootcheck and YARA each see on an endpoint

Rootcheck and YARA look for different kinds of evidence, and a Wazuh deployment gets the most value when the team knows which one raised an alert and why. Rootcheck is the Wazuh module that inspects an endpoint's state for signs of compromise. It looks for indicators such as processes that do not appear in the normal process listing, files with suspicious permission settings, system binaries that differ from what is expected, and traits associated with known rootkits. Its checks run on the agent, and the findings are reported to the Wazuh server as alerts. YARA works differently. It applies rules that describe text strings or byte sequences, and optional conditions about a file, to the contents of files on disk. A match means a file contains a pattern that a rule author decided is characteristic of malicious code.

The practical difference is between known bad patterns and anomalies. A YARA rule is a signature: it encodes a pattern someone has already seen or expects to see, so it is precise when the pattern is distinctive and blind to variants that change it. Rootcheck's rootkit trait checks and YARA rules both lean toward known indicators. Anomaly-style findings, such as a hidden process or an unexpected permission state, do not name a specific malware family. They flag a deviation from a baseline that may have a benign cause, such as a legitimate administrative tool, a package update, or a software product that behaves unusually. Each approach catches things the other misses, and each produces false positives that someone must review.

Neither method proves an infection on its own. A rootcheck finding is an indicator that needs corroboration from logs, file integrity monitoring, process and network records, or a responder's inspection of the host. A YARA match shows that a file contains a pattern. It does not show that the file ran, that it was placed by an attacker, or that it is the only copy. Plan the response workflow before alerts arrive: who reviews each alert type, what evidence is collected, and when a host is isolated. Treat the first alert as a lead to investigate.

Before relying on either module, confirm current behavior in the documentation for your Wazuh version. Check which rootcheck checks run by default on each operating system, how the rootkit trait and file database are maintained, and which options control scan frequency. For YARA, confirm the rule formats the Wazuh server accepts, how rule files are loaded and organized, and which directories and file types the scanning configuration covers. Test each rule set on a staging agent with known benign files to measure how often it fires before it reaches production. Record the versions you tested, because the checks and accepted formats can change between releases.

Ask your implementation partner or internal team to document three things for each detection method: the indicators it can see, the indicators it cannot see, and the evidence needed before an alert becomes an incident. This document also sets expectations for the security operations staff who will triage alerts, and it helps auditors and reviewers understand that these are detection aids, not proof of compromise.

Setting up file-triggered YARA scanning step by step

This sequence takes Wazuh from an inventory of agents to a tested pipeline in which file changes trigger YARA scans and rootcheck runs, and matching alerts reach the dashboard for every agent group. Each step ends with a check so the team can confirm the result before moving on.

Confirm agent versions and operating systems
The security engineer exports the list of agents with their operating system, agent version and group membership from the Wazuh server. Confirm that each agent runs a version supported with the server's release line and that the operating systems in scope are the ones your agents support, such as Linux and Windows. Record any agents on older or unsupported versions as upgrade items before changing configuration. The step is complete when every in-scope agent is listed as active, with its version and group recorded in the scope document.
Decide which directories and events trigger scans
The security lead works with the application and platform owners to choose the directories where a new or modified file is most likely to be malicious, such as web roots, upload folders, user download locations and startup paths. Decide whether each path should be watched in real time or checked on a schedule, and list the paths to exclude because they generate high volumes of expected change. Write the decision as a signed scope table per agent group. The step is complete when each watched path has an owner, a trigger type and a documented reason, and a controlled test file written to each path produces a file change event on the server.
Deploy YARA rule files through agent configuration
The platform engineer places the YARA rule files in version control and adds them to the centrally managed agent configuration for each agent group, so the server pushes the same rules to every agent in that group. Avoid editing files on individual endpoints, because local changes drift from the managed configuration and are hard to audit. Confirm the exact configuration option names and rule file locations for your release line in the Wazuh documentation before you edit the shared configuration. The step is complete when the agent logs on each group show that the rule file loaded without errors after the configuration push.
Enable the rootcheck module by group
The platform engineer enables the rootcheck module in the same managed configuration, scoped to the agent groups that need it, so rootkit and system anomaly checks run alongside the YARA scanning. Review the default rootcheck settings with the operations team and note which findings the team expects on each operating system, because some system checks produce findings that need tuning. Keep the configuration change in the same review as the YARA change so both are tested together. The step is complete when a test agent in each group reports rootcheck results to the server and those results are visible in the dashboard.
Send benign test files to trigger alerts
The security engineer places harmless sample files in each watched path on a test agent, using files that contain only the marker string the YARA rule is written to match. Keep the samples in a test-only location, label them clearly and remove them after testing. The analyst then confirms that each sample produces a file change event, a YARA match and an alert in the dashboard, with the expected rule name. The step is complete when every watched path has produced the expected alert and no unexpected alerts appear for unchanged files.
Review decoded events and tune the rules
The analyst opens each test alert and reviews the decoded event fields, including the agent name, file path, rule identifier and the matched content reference, to confirm the server decoded them correctly. Any missing or misnamed field is traced back to the decoder or rule configuration before production use. The team also records the alerts from normal, expected file activity so that noisy rules or paths can be adjusted. The step is complete when each test alert shows the correct agent, path and rule, and the tuning changes are committed to version control.
Confirm alert delivery for every agent group
The operations lead repeats the test on at least one agent from every agent group, because a rule that loads on one group can still fail on another with a different operating system or configuration. The lead then checks that the alerts appear in the dashboard for the correct group, that the rule file load status is clean on every group, and that the retention and access settings match the team's policy. Confirm the expected alert routing and any notification steps with the team that will respond to alerts. The step is complete when every group has passed the same test and the results are recorded for the change record.

Collecting ClamAV and Windows Defender logs into Wazuh

Antivirus events help malware detection only when they reach Wazuh as parsed, searchable fields. The cards below follow one path: collection on each endpoint, decoding and rules on the Wazuh server, verification in the dashboard, and checks that catch a stopped scanner before silence is mistaken for safety.

Collecting ClamAV logs on Linux

ClamAV on Linux writes scan and daemon output to log files or the system journal, depending on how your distribution packages it. The Wazuh agent reads these sources through its log collection settings and forwards events to the Wazuh server. Confirm which log file or journal unit your ClamAV build writes, who owns the file permissions, and whether the agent user can read it. Test collection on one host before rolling the configuration out to the fleet.

Collecting Defender logs on Windows

Microsoft Defender records detections, scans and remediation actions in Windows event logs, and the Wazuh agent on Windows collects the event channels you configure. Choose channels deliberately, because collecting everything increases event volume and collecting too little misses detections. Confirm which Defender channel and event types your Windows build produces, and whether endpoint management tooling already changes Defender policy or logging.

Matching decoders and rules to log formats

A Wazuh decoder extracts fields from a log line on the Wazuh server, and a rule matches on those fields to raise an alert. If the decoder expects a different layout from what ClamAV or Defender actually produces, events arrive without useful fields and no rule fires. Start from samples of actual output from your own systems, record the product versions that produced them, and revise decoders whenever a version upgrade changes the format.

Verifying parsed fields in the dashboard

After collection, check that each antivirus event appears in the dashboard with the fields your alert rules depend on, such as file path, threat or signature name and action taken. Use the Wazuh log test tool on the server with sample lines to confirm decoding before waiting for production events. Then run a harmless test detection on a non-production host, such as the standard EICAR test file, and confirm the resulting alert shows the expected fields in search.

Detecting a stopped antivirus service

An endpoint with a stopped ClamAV daemon or Defender service produces no detection events, so silence can look like a clean system. Monitor the service state itself, through agent-reported status or a rule that alerts when expected scan or heartbeat events stop arriving. Treat a host that goes quiet as a finding to investigate before assuming it is clean.

Confirming formats and retention locally

Before finalizing rules, confirm with your platform owners which ClamAV and Defender versions are deployed, which log formats they emit and whether those formats change between releases. Also confirm how long endpoints keep local logs, how long the Wazuh indexer retains alerts under your settings, and who approves archiving of raw events. These answers set how far back an investigation can reach.

Tuning YARA and rootcheck alerts so analysts trust them

Tuning decides whether analysts keep reading Wazuh malware alerts. A YARA or rootcheck rule that fires on normal software will be muted within weeks, and a muted rule stops detecting anything. The work starts by identifying where false positives come from in your environment, then changing scope, exclusions and alert levels in a controlled way. The most common sources are noisy rules, overlapping file paths and build or package directories. A YARA rule written for web shells may match compiled code, minified JavaScript or test fixtures in a developer tree. Scheduled file-integrity scans that cover the same paths through more than one configuration can raise duplicate alerts for one event. Build outputs, package caches and container layers change constantly and look suspicious to a generic rule. Review a sample of recent alerts for each rule and group them by path and by the process that wrote the file before deciding what to change.

Scope is the first control. Limit YARA scanning to directories where unexpected executable or script content has no legitimate reason to appear, and avoid recursive scans of whole volumes unless you have measured the load and the noise. Exclude known safe trees such as vendor-managed package directories, build workspaces and developer checkouts only after confirming who owns them and how they are updated. Keep each exclusion narrow and record the reason next to it, so a reviewer can later see why a path is excluded and whether that reason still holds. Do not exclude a parent directory to silence one child path. Alert levels should differ by agent group. A database server, a domain controller and a developer workstation carry different risk and different normal activity, so one global threshold will either flood the analysts or hide real findings on the servers that matter most. Assign agent groups by role, set higher severity for rules that match on production hosts, and route low-confidence matches on developer groups to a review queue rather than the main alert stream. Confirm how your Wazuh version applies group-level configuration and check that the group assignment is the one the agent actually receives.

Tuning is ongoing work, not a one-time setup. Software changes on endpoints, such as a new build pipeline, a framework upgrade or a new vendor agent, can create new matches for existing rules. Assign an owner for the rule set, link each tuning change to the change that caused the noise, and review alert volume after every significant software rollout on the monitored groups. Ask any partner or internal team to show how they track these changes and how long they keep the history. Every change should be tested against a sample set before it reaches production agents. Build a sample that includes known-good files from the affected trees, known-bad test files that the rule must still detect, and recent alerts that were judged false positives. Run the modified rule or exclusion against that set, confirm that the detections remain and the noise falls, and only then deploy it to a pilot agent group. Keep the sample set under version control so the same test can be repeated after each Wazuh upgrade and each rule change.

Hash lists versus VirusTotal lookups: trade-offs to decide

A hash list checks file hashes against a set you maintain internally or import from a threat-intelligence source. Matching happens inside your own environment, so no file data leaves the network. The approach works best when you know which files or families matter to your organization and can keep the list current.

Source quality: Hashes from internal incident work or a vetted threat-intelligence feed are only as good as their provenance. Record where each entry came from and when it was last reviewed.
Maintenance: Lists go stale. Plan an owner, a review cadence and a removal process for hashes of files that are no longer relevant or were later found to be benign.
Format and loading: Confirm the list format and how Wazuh loads and reloads it in your version, and test that a known-bad sample alerts after each change.
Blind spot for modified files: A hash changes whenever a file is altered, even slightly. A recompiled or repacked variant of a known sample will not match, so the list catches known files, not new variants.
Coverage gaps: Files that were never seen by your team or your feed will not appear in the list at all.

Before relying on this option, confirm which hash algorithms your Wazuh version supports for matching and who will own the list after go-live.

Security and operational risks of malware detection in Wazuh

Malware detection in Wazuh adds sensitive content to your environment: detection rules, scan paths, third-party API keys and file samples. The cards below cover the security controls that protect that content and the operational decisions that determine whether alerts lead to action.

Protecting the rule repository

YARA rules, hash lists and rootcheck policies define what Wazuh treats as malicious or suspicious. Store them in version control with restricted write access, require review for changes, and keep the deployed copies on the Wazuh server and agents aligned with that source. Check that an agent or server user without administrative rights cannot modify rule files that the analysis depends on.

Controlling who changes scan paths

Scan directories and file-change monitoring paths determine what Wazuh examines and what it ignores, so an unexpected change can silently remove coverage. Limit edit rights to the agent configuration to a named group, and review changes to directories that include temporary or user-writable locations. Confirm that agent configuration changes made through remote management are logged and attributable.

Keeping VirusTotal API keys out of plain text

A VirusTotal lookup in the Wazuh server configuration requires an API key, and a key stored in a plain-text file exposes the account to anyone who can read that file. Confirm where the key is stored, who can read the configuration on the server, and whether the key is included in backups or support bundles. Plan rotation and confirm the procedure with the current Wazuh documentation for your release.

Controlling file samples leaving the environment

Lookups that send file hashes or content to an external service can disclose internal documents, proprietary code or personal data. Decide in advance which file types, paths and alert types may trigger an external query, and record that decision with the data owners. Confirm with the service provider what is sent, how it is retained and whether your data handling terms allow it.

Applying access controls to malware alerts

Malware alerts often include file paths, usernames, hashes and process details that reveal sensitive activity. Store them in the Wazuh indexer under the same role-based access model as other security data, and restrict dashboard views and saved searches to the analysts who need them. Review who can export alerts, since exported files leave the controls of the platform.

Measuring scan load on endpoints and the server

Scanning files with YARA on file changes adds CPU, disk input and output on endpoints, and high-volume directories can delay other workloads. Pilot the scan scope on representative hosts, measure the effect on each host type, and exclude high-churn paths that do not warrant inspection. Plan indexer and server capacity for the alert volume that the chosen scope produces.

Assigning alert triage ownership

Malware alerts from rootcheck, YARA and hash matches reach analysts only if a named team owns the queue. Define who reviews new alerts, who suppresses known false positives, who approves rule changes, and the response time expected for each severity. Without this ownership, high-volume detections become background noise and real infections are missed.

Connecting alerts to incident response runbooks

Each malware alert type should map to a documented runbook step, such as isolating a host, collecting a file sample under chain of custody, or escalating to the incident commander. Write the trigger conditions, the evidence to capture and the decision owner for each runbook, and test the path with a tabletop exercise. Confirm how alerts are forwarded to ticketing or SOAR tools with your integration design.

Questions teams ask before hiring help with Wazuh malware detection

How much effort does Wazuh malware detection setup take?

Effort depends mainly on the scope you set, not on the software license, because self-hosted Wazuh is open source with no license fee. The main drivers are the number of endpoints and their operating system mix, since Windows, Linux and macOS hosts need different checks and log sources. Rule tuning is usually the largest variable. YARA scans triggered by file changes and rootcheck findings both generate alerts that must be reviewed and adjusted before they are useful. Two decisions also change the work: whether file hashes or samples may be sent to VirusTotal, and how complete your existing antivirus logging already is. Ask any partner to show how each driver is estimated in a written scope.

How long does a Wazuh malware detection engagement usually take?

Duration depends on the agreed scope, so there is no single figure that applies to every environment. A narrow scope, such as rootcheck on one endpoint group, moves faster than YARA rules, hash lists, VirusTotal lookups and ClamAV or Windows Defender log collection across mixed fleets. Change windows, approval cycles and the length of the tuning period also affect the calendar more than the technical build does. Fixed-scope work is agreed in writing before it starts, so ask for the phases, the dependencies between them, the tuning window and the points where your team must sign off. Those milestones are what you can hold a partner to.

What must our team provide before a partner starts the work?

Your team needs to provide access, decisions and people. Access means administrative paths to the Wazuh server, the indexer and the dashboard, plus permission to deploy or update agents on the endpoints in scope. Change windows are needed for agent rollouts and configuration changes that touch production hosts. Sample files for YARA testing should be provided through a controlled process approved by your security team, with clear handling rules. Finally, name an owner for each alert category who will accept or close findings, because detections without an owner tend to stop being reviewed. Confirm each item in the written scope so responsibilities are clear before work begins.

Can our internal security team set this up without outside help?

Yes, a capable internal team can build this with the Wazuh documentation, provided it has the skills and time for the work. The skills that matter most are Linux and Windows administration, familiarity with Wazuh decoders and rules, practical YARA rule writing, and enough understanding of endpoint security tools to interpret Defender and ClamAV logs. The harder part is usually sustained tuning, because false positives must be reduced without hiding real activity. Ask whether your team can staff that tuning period and whether it has an alert owner on call. An outside partner can shorten the build, but it does not remove the need for your team to own the detections afterward.

Should we send file hashes or samples to VirusTotal?

This is a data governance decision, and it should be made before any lookup is configured. A VirusTotal lookup sends the hash or file to an external service, so the question is whether your policy, contracts and data classification allow that for the files involved. Files from regulated systems or those containing personal or confidential data often need a stricter answer than public software binaries. If external lookups are not allowed, the design can rely on local hash lists and YARA rules instead. Review the current VirusTotal terms and your own policy, and record the decision and its owner in the written scope.

What usually goes wrong in Wazuh malware detection deployments?

The most common problems are operational rather than technical. YARA rules that scan broadly on file changes can create load on busy hosts and flood the alert queue. Rootcheck findings on hardened or unusual systems often need baseline work before they are meaningful. Antivirus logs from ClamAV or Windows Defender may be missing or unparsed, which leaves gaps that look like coverage. Alerts without a named owner are often ignored. Finally, the release line receives patches every one to two months, so rules and decoders can change after an upgrade. Build testing, owners and an upgrade check into the plan from the start so these issues are caught early.

What should a written scope for this work include?

A useful written scope lists the endpoint groups and operating systems in each phase, along with the detection components to be built: rootcheck, file-change triggered YARA scanning, hash lists, VirusTotal lookups and any antivirus log collection. It should record the VirusTotal decision, the sample-handling process and the change windows. It should also name alert owners, define how tuning is measured and state what is handed over at the end, including documentation and runbooks. Ask what ongoing support is included, since the self-hosted software needs upgrades as patch releases arrive. Each deliverable should have a clear acceptance check so both sides agree when it is complete.

Limits to confirm in your environment before relying on Wazuh for malware detection

Wazuh malware detection depends on which release you run, which endpoints you cover and how your file servers and networks behave. The cards below list the limits your team should confirm with the Wazuh documentation for your exact version and with a test on representative endpoints before treating alerts as coverage.

Detection methods in your release

Rootcheck, file integrity monitoring, YARA scanning triggered by file changes, hash lists and VirusTotal lookups are not all configured the same way across releases. Your team should confirm that the release you run supports each method as the documentation describes it, and record the exact version in your test plan. Current patch releases in the 4.14 line are a useful starting point, but the behavior you rely on must be checked against the documentation for that version.

Operating system and agent coverage

Agents run on several operating systems, but the malware checks you need may not behave identically on every platform or agent version. Build a matrix of the operating systems, distributions and agent versions in your estate, then confirm for each one which detection methods apply. Gaps usually appear on older hosts, specialized Unix systems and endpoints where the agent cannot run the scanning component.

YARA performance on large file servers

YARA scanning triggered by file changes consumes CPU and I/O, and the cost grows with the volume of changed files, the size of the rule set and the number of monitored paths. Test on a file server that resembles production, with realistic write rates and a rule set of the size you plan to deploy. Measure the scan backlog, the effect on user workloads and how long alerts take to appear before you widen the monitored paths.

Offline and restricted networks

Some lookups, updates and integrations assume outbound connectivity, including VirusTotal queries and vulnerability data feeds. Confirm which malware detection features run in full offline mode, which need a local copy of rules, hash lists or threat data, and which need a proxy or an external service. Check the Wazuh offline installation guide for your version, then test the rule and data updates you will need to move across the boundary.

Detection layer, not endpoint protection

Wazuh alerts on suspicious files, changed system state and known indicators, but it does not block execution or quarantine files the way a dedicated endpoint protection product does. It also does not replace a forensic tool for memory capture, disk imaging or chain-of-custody work. Decide in advance which team acts on each alert, which response tools are in place and whether the Wazuh findings feed an incident process that already exists.

Testing against representative endpoints

Vendor documentation describes expected behavior, but your results depend on your images, policies, security tooling and network paths. Before go-live, run known-safe test samples and controlled changes on a sample of each endpoint class, and record which alerts fire, how quickly they arrive and which ones are missing. Repeat the test after each Wazuh upgrade, because a release change can alter detection behavior.

How DeployOpen scopes and delivers Wazuh malware detection

DeployOpen plans and implements Wazuh malware detection inside your own infrastructure, starting from which hosts, file paths and log sources matter to your security team. The work covers rootcheck, file-change-triggered YARA scanning, hash lists, VirusTotal lookups and collection of ClamAV and Windows Defender logs, with each part tuned to your environment and documented for the team that will run it.

How we scope

Written scope lists the endpoints, operating systems and file paths in which rootcheck and YARA scanning will run.
Scope states which YARA rule sources, hash lists and VirusTotal lookups are in use, and who approves each source.
Scope confirms whether ClamAV and Windows Defender logs are collected, and which Wazuh components receive them.

How we build

Rootcheck and file integrity settings are configured per operating system and tested against known-good hosts before rollout.
YARA rules are wired to file-change events, then tested on sample files to measure false positives on your own software.
Hash lists and VirusTotal lookup settings are configured with API key handling and rate limits reviewed with your team.

How we hand over

Deliverables include configuration files, custom rule sets, decoder notes and a record of every tested detection case.
Runbooks describe how analysts triage a YARA or rootcheck alert, including when to escalate and how to add exceptions.
Knowledge transfer sessions cover rule ownership, change control for YARA content and how to review alert volume over time.

How we support

Ongoing support, rule updates and periodic tuning are available as a retainer after handover.
Retainer work can include reviewing new Wazuh releases for changes that affect rootcheck, YARA or log collection.
Your team confirms current Wazuh version support and upgrade timing with DeployOpen before each change window.