I Added AI to Wazuh: YARA Alert Enrichment Explained

I Added AI to Wazuh: YARA Alert Enrichment Explained

AI has found its way into almost every security product, dashboard, and release note. Quite often, it amounts to a chatbot bolted onto the side.

This Wazuh integration has a more practical job. When a file lands on a monitored Windows endpoint, Wazuh triggers YARA. If the file matches one of the rules, Active Response removes it and sends the rule description to an LLM. The generated explanation then appears inside the Wazuh event alongside the original detection data.

The result is useful, but only if we are clear about what each component is doing:

• Wazuh File Integrity Monitoring notices the new or modified file.
• YARA scans the file and makes the detection.
• Wazuh Active Response runs the workflow and removes a positive match.
• The LLM explains the YARA rule context in plain English.
• Wazuh ingests the combined result as a searchable security event.

The AI does not inspect, reverse engineer, or independently classify the file. It explains the context it receives. That boundary matters when we decide how much to trust the answer.

This is an isolated-lab proof of concept based on Wazuh's official documentation. It is not a built-in “enable AI” switch, and the sample workflow automatically deletes matching files. Do not deploy it unchanged in production.

What We Are Building

The complete event path looks like this:

FILE CHANGE
    ↓
WAZUH FIM
    ↓
YARA SCAN
    ↓
ACTIVE RESPONSE REMOVES A MATCH
    ↓
LLM EXPLAINS THE RULE CONTEXT
    ↓
ENRICHED WAZUH EVENT

This is different from asking a general-purpose chatbot to review an alert after the fact. The enrichment is added while the response workflow is running, so an analyst can see the YARA result, affected file, deletion outcome, and generated explanation in the same event.

Prerequisites

For the Windows version of this lab, you will need:

• A working Wazuh server and Windows 11 agent
• Administrator access to the Windows endpoint
• Python installed with python.exe added to PATH
• The Microsoft Visual C++ Redistributable
• An OpenAI API key and a supported model name
• A disposable lab endpoint for safe testing

If you do not have Wazuh running yet, start with my free Wazuh SIEM home-lab guide.

Step 1: Install YARA on the Windows Endpoint

Open PowerShell as Administrator. The current Wazuh proof of concept uses YARA 4.5.1 for its Windows example:

Invoke-WebRequest `
  -Uri https://github.com/VirusTotal/yara/releases/download/v4.5.1/yara-v4.5.1-2298-win64.zip `
  -OutFile yara-v4.5.1-2298-win64.zip

Expand-Archive yara-v4.5.1-2298-win64.zip
Remove-Item yara-v4.5.1-2298-win64.zip

Create a dedicated directory beneath the Wazuh Active Response folder and copy in the YARA executable:

New-Item -ItemType Directory `
  -Path 'C:\Program Files (x86)\ossec-agent\active-response\bin\yara' `
  -Force

Copy-Item `
  '.\yara-v4.5.1-2298-win64\yara64.exe' `
  'C:\Program Files (x86)\ossec-agent\active-response\bin\yara\'

If Windows rejects the copy, check that PowerShell is running as Administrator. The Wazuh agent directory is protected, so a normal terminal will not have permission to write there.

Step 2: Download a YARA Ruleset

The Wazuh example uses Nextron Systems' Valhalla API to retrieve a demo ruleset:

python -m pip install valhallaAPI

python -c "from valhallaAPI.valhalla import ValhallaAPI; v = ValhallaAPI(api_key='1111111111111111111111111111111111111111111111111111111111111111'); response = v.get_rules_text(); open('yara_rules.yar', 'w').write(response)"

Create the rules directory and copy the downloaded file into it:

New-Item -ItemType Directory `
  -Path 'C:\Program Files (x86)\ossec-agent\active-response\bin\yara\rules' `
  -Force

Copy-Item `
  '.\yara_rules.yar' `
  'C:\Program Files (x86)\ossec-agent\active-response\bin\yara\rules\'

The enrichment depends on the YARA rule's description metadata. If you replace the demo rules with your own, make sure each rule you want to enrich includes a meaningful description.

Step 3: Create the Active Response Wrapper

Wazuh's Windows proof of concept uses a Python wrapper that:

1. Reads the file path from the Active Response JSON input.
2. Runs yara64.exe against that file.
3. Extracts the matched rule's description.
4. Sends that description to the configured LLM.
5. Writes the YARA result and generated explanation to the Active Response log.
6. Deletes the matching file.

Use the current yara.py example in Wazuh's official guide as the starting point. Save it as:

C:\Program Files (x86)\ossec-agent\active-response\bin\yara.py

Replace the placeholders near the top of the script with your API key and chosen model.

Do Not Treat the Embedded API Key as Production Design

The proof of concept hard-codes the API key in the script, which is simple for a disposable lab but unsuitable for production. A real deployment should use an approved secret store or tightly controlled environment configuration, restrict the key, monitor its use, and decide whether the alert context is permitted to leave the environment.

The prompt also deserves scrutiny. The model sees the YARA description, not the underlying file. Keep the instruction narrow and make sure the output is presented as generated context rather than a verified conclusion.

Step 4: Package the Wrapper for Active Response

Install PyInstaller and convert the Python wrapper into a single executable:

python -m pip install pyinstaller
python -m PyInstaller -F "C:\Program Files (x86)\ossec-agent\active-response\bin\yara.py"

PyInstaller normally writes yara.exe to a dist directory beneath the current working directory. If you ran the command from an elevated shell opened in C:\Windows\System32, check C:\Windows\System32\dist.

Copy the finished executable into the Wazuh Active Response bin directory:

Copy-Item `
  '.\dist\yara.exe' `
  'C:\Program Files (x86)\ossec-agent\active-response\bin\yara.exe'

Step 5: Monitor the Downloads Folder

Open the Windows agent configuration file:

C:\Program Files (x86)\ossec-agent\ossec.conf

Inside the existing <syscheck> section, add:

<directories realtime="yes">C:\Users\*\Downloads</directories>

Restart the Wazuh agent from an elevated PowerShell window:

Restart-Service -Name wazuh

Monitoring every user's Downloads folder makes the demonstration easy to follow, but it may be too broad for a real environment. Choose a directory that matches your use case and test the performance and response impact before expanding coverage.

Step 6: Configure the Wazuh Server

The manager needs three pieces of configuration:

• A decoder to turn the wrapper's log line into searchable YARA.* fields
• Local rules for file changes, YARA matches, and deletion results
• An Active Response command that runs yara.exe on the Windows agent

Wazuh provides the complete decoder and rule blocks in the official alert-enrichment guide. Add them to:

/var/ossec/etc/decoders/local_decoder.xml
/var/ossec/etc/rules/local_rules.xml

For the Windows workflow, the important manager configuration is:

<command>
  <name>yara_windows</name>
  <executable>yara.exe</executable>
  <timeout_allowed>no</timeout_allowed>
</command>

<active-response>
  <disabled>no</disabled>
  <command>yara_windows</command>
  <location>local</location>
  <rules_id>100302,100303</rules_id>
</active-response>

Place these blocks inside an <ossec_config> section in /var/ossec/etc/ossec.conf, then restart the manager:

sudo systemctl restart wazuh-manager
sudo systemctl status wazuh-manager --no-pager

Do not skip the status check. During my build, the manager refused to restart because several XML closing tags were malformed. A file that saves successfully is not necessarily a configuration Wazuh can load.

Step 7: Test the Complete Workflow

Only test with benign samples supplied for security-product validation, and only inside an isolated lab. Wazuh links three samples in its proof-of-concept guide. For example:

curl "https://raw.githubusercontent.com/wazuh/wazuh-documentation/refs/heads/4.14/resources/samples/webshell" `
  -o "$env:USERPROFILE\Downloads\webshell"

Windows Defender may quarantine the sample before YARA sees it. That is the safer real-world result: one control stopped the file before the next control had to act.

For this demonstration, I temporarily excluded the test directories on a disposable VM so I could observe the complete Wazuh chain. Do not exclude your normal Downloads folder or YARA rules directory on a production endpoint just to make this proof of concept work.

In the Wazuh dashboard, open the security events view and filter for:

rule.groups:yara

Open the latest positive-match event and check these fields:

• YARA.rule_name
• YARA.rule_description
• YARA.scanned_file
• YARA.chatgpt_response
• The separate Active Response event confirming whether the file was deleted

If the API key is invalid, or the matched YARA rule has no description, the generated response may be recorded as None. Check the endpoint's Active Response log when troubleshooting:

C:\Program Files (x86)\ossec-agent\active-response\active-responses.log

Is the AI Explanation Actually Useful?

In my test, the enriched event described why the matched web shell was suspicious, the access it could provide to an attacker, and sensible investigation or mitigation ideas. That is useful when the alternative is seeing an unfamiliar rule name and starting a separate search from scratch.

The value is speed, not certainty.

The model generated its answer from the YARA rule description. It did not open the file, inspect its behaviour, validate the hash, or review the surrounding endpoint activity. A polished paragraph can still be incomplete or wrong.

Treat the response as a lead. Before putting the conclusion into an incident record, validate it against:

• The underlying YARA rule and its source
• File hashes and reputation data
• The full file path and creation context
• Process, user, and network activity around the event
• Other endpoint and identity telemetry

That makes the feature a useful starting point for triage without turning generated text into evidence.

So, Does Wazuh Have AI Now?

The honest answer is more nuanced than a headline suggests. Wazuh has published official AI integrations and proof-of-concept projects, and its APIs make more advanced automation possible. The alert-enrichment workflow in this guide works today, but it is not the same as every Wazuh installation containing a finished AI analyst.

For this particular integration, the division of labour is simple:

YARA = DETECTION
LLM  = EXPLANATION

That is also the safest way to evaluate it. Keep deterministic detection and original telemetry visible, label generated content clearly, and require an analyst to verify important conclusions.

What I Would Change Next

The most interesting next step is to replace the external API with a local model through Ollama. That could keep alert context inside the lab and remove the hard-coded third-party API key, although it introduces its own model-quality, resource, and maintenance trade-offs.

The other route is Wazuh's newer agentic threat-hunting proof of concept, which can query Wazuh data and plan a multi-step investigation. That is a larger jump in capability—and a larger permissions and evidence-handling problem—so it deserves a separate build and test.

Key Takeaways

• Wazuh FIM detects the file change and triggers the response chain.
• YARA makes the malware-pattern detection; the LLM does not.
• Active Response can remove a matching file and record the outcome.
• The LLM adds fast, readable context to the Wazuh event.
• Generated context should guide investigation, not replace evidence.
• The example is a proof of concept and needs secret management, data-governance review, and safer response controls before production use.

Additional Resources

• Wazuh: Leveraging LLMs for alert enrichment
• Wazuh: Detecting malware using YARA integration
• Wazuh: Threat hunting with Agentic AI
• YARA releases
• OpenAI API documentation

Want to see the full build, including the XML mistake, Windows Defender interference, and the final enriched event? Watch the accompanying video walkthrough above.