# wazuh-virustotal-yara

Companion files for the lesson [Wazuh Malware Detection with VirusTotal and YARA](https://maheshtata.com/wazuh/wazuh-virustotal-yara/).

Tested against the Wazuh 5.0 beta5 documentation (September 2026). Wazuh 5.0 is
still in beta, so treat every value as subject to change at GA.

| File | What it is | Where it goes |
| --- | --- | --- |
| `yara-scan.py` | Stateless custom active response script that runs YARA against the file named in the triggering finding | `/var/ossec/active-response/bin/yara-scan` on Linux |
| `malicious-hashes.kvdb.json` | Sample SHA-256 blocklist content for a KVDB | pasted into Security Analytics > KVDBs > Actions > Create |

## What is documented and what is not

Wazuh 5.0 beta ships **no VirusTotal integration and no YARA module**. The
`integratord` daemon and the `<integration>` blocks were removed, and the
official migration guide states that bi-directional enrichment integrations
such as VirusTotal and Maltiverse cannot be migrated because 5.x has no
equivalent mechanism.

What **is** documented, and what these files rely on:

- The active response JSON message format delivered on STDIN, including the
  `command` field and the WCS fields carried from the triggering finding.
- The script directories and the required ownership and permissions.
- The `active-responses.log` paths on Linux, macOS and Windows.
- The Alerting active response monitor and its constraints.
- KVDBs as a string key paired with a JSON value, and the helper function
  names (`kvdb_get`, `kvdb_match`, and the rest).

What is **not** documented and is therefore this repository's own design:

- The YARA command line and how its output is parsed.
- The `yara-scan-result` JSON line written to the active response log.
- The value shape inside the KVDB entries.

## Install the active response script

```bash
sudo cp yara-scan.py /var/ossec/active-response/bin/yara-scan
sudo chmod 750 /var/ossec/active-response/bin/yara-scan
sudo chown root:wazuh /var/ossec/active-response/bin/yara-scan
```

macOS uses `/Library/Ossec/active-response/bin/`. Windows uses
`C:\Program Files (x86)\ossec-agent\active-response\bin\`, and the Windows
agent executes active responses as executables, so convert the script with
PyInstaller or call it through a `launcher.cmd` wrapper.

Edit the TODO block at the top of the script before deploying: the YARA binary
path, the compiled rule file, the scan timeout and the maximum file size.

## Register it

1. Explore > Active Responses > Create active response.
   Name `yara_scan_ar`, Executable `yara-scan`, Location `Local`,
   Type `stateless`. No manager restart is needed.
2. Explore > Alerting > Monitors > Create monitor, Monitor type
   `Active response`. Index `wazuh-findings-v5-system-activity`.
   Add `yara_scan_ar` as an action on the trigger.

Documented constraints on an active response monitor:

- target indices must match `wazuh-findings-v5-*`
- maximum execution interval of 1 minute
- `DocumentLevelTrigger` only
- the Alerting module supports up to 10 custom monitors per user

## Notes

- Scan results land in the endpoint's `active-responses.log`. To turn them into
  findings you must collect that file with `<localfile>`, write your own
  decoder, and write your own rule. Wazuh ships none of the three for YARA.
- Execution records go to the `wazuh-active-responses` index, which keeps
  3 days by default under the `stream-active-responses-policy` ISM policy.
- Keep active response switched off until the detection that drives it has been
  tuned. A YARA scan is cheap; a scan loop on a directory a package manager
  touches is not.
- `malicious-hashes.kvdb.json` contains the EICAR test file SHA-256 so you can
  prove the lookup path works without handling live malware. Remove the
  `_comment` key before pasting the content into the dashboard form.