Wazuh and VirusTotal integration

The path has four stages, and each one can lose or delay an alert. First, a Wazuh agent on an endpoint with file integrity monitoring enabled detects a change in a monitored directory and reports it to the Wazuh server. The server decodes that event and applies its rules. For the agent groups and rules you have scoped, it generates a file integrity alert. The Wazuh indexer stores that alert, and the Wazuh dashboard reads it from there. Before you assume a lookup will follow, confirm in your own environment which groups and directories produce events, because a change that never becomes an alert will never reach VirusTotal.

The integration step is the one that reaches outside your network, so it needs the most scrutiny. The integration takes the file hash from the alert and submits it to VirusTotal for lookup. Confirm which hash algorithms the documented integration supports, such as MD5, SHA-1 or SHA-256, because the algorithm determines which VirusTotal records can match and which hash field the alert must carry. Also confirm whether the lookup runs for new files, for modified files, or for both. That choice drives how many requests your API key makes, and it affects how many endpoints can be checked during a busy period.

The verdict returns as a new event rather than as an edit to the original alert. Wazuh then processes that event like any other: it is indexed, it appears in the dashboard, and rules can match it. Decide early which fields the verdict event carries, such as the detection count or the hash it refers to, and confirm those field names against the documented integration before writing any rule. A rule that matches a field the event does not carry will never fire, and nothing will report the failure. Expect a delay between the original file change and the verdict, and design alerting so that the first alert is not the only signal you rely on.

Because the lookup is one step in a chain, a missing result can come from any stage. The agent may be offline, the server rule may not match the event, the API key may hit its request limit, or the verdict event may not be indexed. Test each stage with a controlled file change in a non-production group, then trace that change through the alert, the lookup and the verdict on the dashboard. Keep a record of what the test showed at each stage. That record gives you a baseline for the rate limit and rule checks covered elsewhere on this page, and it shows your team where to look first when a real detection goes quiet.

The public VirusTotal API applies request limits, so the design has to fit inside them before the integration goes live. Confirm the current limits and terms on VirusTotal's own documentation before sizing anything, because they can change and figures in older articles or forum posts may be out of date. The risk is specific to file integrity monitoring. Every created or modified file in a watched path can become a hash lookup candidate, so a busy policy on a fleet of endpoints can generate more lookups per day than the public API allows. Estimate that volume from your own change rates, not from a generic assumption.

Scoping monitored paths is the first control. In the Wazuh agent configuration, the file integrity monitoring directories define what gets checked, so limit them to locations where an unexpected change matters, such as system binaries, startup locations and web roots. Then exclude high-churn directories such as temporary folders, package caches, browser profiles, log directories, container layers and application upload stores, using the ignore settings the Wazuh documentation describes for your agent version. Record a reason for each exclusion. Security reviewers will ask why a path is not checked, and the answer should be written down before go-live.

Deduplication and event selection reduce volume further. The same file hash appears many times across a fleet, for example when a software package is installed on hundreds of machines, so confirm whether your integration version avoids repeated lookups for a hash it has already checked, and add caching if it does not. Next, decide which events trigger a lookup. Options include only newly created executables, only changes in certain directories, or only events at or above a defined rule level. The Wazuh rules and integration filters control what reaches the lookup step, so test those filters against a sample of endpoints and count the lookups per day before rolling out to the full fleet.

The last decision is whether the public key is enough. A public key may suit a lab or a low-volume environment, but a continuous policy across many endpoints can outgrow it. Before choosing a premium or private key from VirusTotal, ask the vendor what the license permits in your context, including whether your file metadata may be submitted, how long results are retained and what support is included. Plan for key storage and rotation as well. Throttled or failed lookups must be logged and retried or alerted on, so an endpoint is never treated as clean simply because the check did not complete. Active response should also depend on a completed lookup result, not on the absence of one.

The first decision is whether Wazuh should act on a VirusTotal verdict at all, or only raise an alert for a person to review. Active response is the Wazuh mechanism that runs a command on the agent when a rule matches, so a VirusTotal-driven rule could in principle trigger a script that deletes or quarantines a changed file. That capability is useful, but deleting a file is destructive and cannot be reversed by Wazuh. A detection that is wrong, or a legitimate file that happens to be flagged by one engine, can remove a configuration file, a library or a database component and break a service. Treat automatic removal as a change to production behavior that needs its own approval, not as a default that comes with the integration.

Before designing anything, confirm the active response options documented for the Wazuh release you run, including which built-in commands exist, how they are triggered, whether they run on the agent or the server, and what they do to a file. Release lines change, and the 4.14 patch releases in 2026 should be checked against the release notes rather than assumed to behave identically. Record the exact agent version too, because active response behavior and script locations depend on it. Where the documented options do not cover the action you want, the custom script is part of the engagement scope, along with its testing and its rollback path.

Start with alert-only rules. Run the VirusTotal-linked rules for a period long enough to see how often they fire on your real file change patterns, which directories generate noise, and which verdicts come from benign software updates. Then add a verdict threshold, so removal is considered only when a defined number of engines flag the file, and pair it with a clear allowlist of paths, hashes and signed software that must never be touched, such as package manager directories, backup agents and security tooling. Test the full chain on non-production agents that mirror your operating systems and file layouts, and confirm that the allowlist, threshold and script behave as intended before any production agent is in scope.

Where the platform allows it, prefer a copy or quarantine step over deletion. Moving the file to a restricted location, keeping a hash and a copy with its metadata, and recording the action in the alert chain lets an analyst reverse a mistake and gives an incident responder evidence. Confirm on each agent operating system whether the quarantine location is protected from the same users and processes that could tamper with it, and what happens to file permissions and ownership during the move. Plan storage capacity and a retention period for quarantined files as an operating task.

Decide before go-live who approves removal on production systems, and document the answer. Options include a human analyst who confirms each action, a change owner who authorizes a defined class of files, or automatic removal limited to specific non-production or low-impact hosts. The approval model should name the roles, the response time expected for a confirmation request, and the path for emergency action. Our engagement designs and tests the removal logic, thresholds, allowlist and quarantine behavior together with your approval model, so the removal path is verified in your environment rather than assumed to work.