What we set out to do:
Every time a file lands on a monitored endpoint, we wanted it automatically checked against a database of known malware signatures — without anyone having to manually run a scan. If something suspicious is found, an alert fires in the SIEM immediately.
The Departments Involved
Think of this as three departments working together:
- Wazuh FIM (The Security Guard) — stands watch over specific folders on the endpoint. The moment a new file appears, the guard radios it in.
- Active Response (The Communication System) — receives the radio call and routes it to the right department automatically. No human intervention required.
- YARA (The Forensics Analyst) — receives the file details, runs it against a database of known threat profiles, and reports back with findings.
- The Log Collector (Internal Post) — carries YARA's findings back to the main office (Wazuh manager) where they're processed and filed as a formal alert.
What Was Built
- The threat database (malware.yar): A YARA rule file containing signatures for known malicious tools — starting with Mimikatz, one of the most commonly used credential theft tools in real attacks. This is YARA's reference guide. When a file contains strings like
mimikatz,sekurlsa, orlsadump, YARA flags it immediately. - The scanning engine (yara-ar.exe): A custom program written in Python and compiled into a Windows executable. This is YARA's phone — the tool that receives the file path from Wazuh, passes it to YARA for scanning, and formats the result so Wazuh can understand and act on it.
- File Integrity Monitoring: Configured to watch two high-risk folders in real time — Downloads and AppData\Temp. These are the locations attackers most commonly use to stage malicious files on a compromised machine.
- The decoder and alert rules: Custom configuration on the Wazuh manager that reads YARA's output, understands what it means, and generates a level 12 alert when a match is found.
The Problem We Had to Solve
The first attempt used a .bat file as the scanning engine. A .bat file is like a handwritten note — simple, but limited in how it receives information from other systems. Wazuh's communication system on Windows couldn't reliably hand off the file details to it. The call was going out but never connecting.
The fix was converting the scanning logic into a proper .exe executable using a tool called pyinstaller. An .exe is a fully packaged application — it speaks the same language as Wazuh's active response system natively. Once we made that change, the communication worked immediately.
The Flow in Action
New file lands in Downloads or Temp → FIM (Security Guard) detects it in real time → Active Response (Communication System) routes the file details to YARA → yara-ar.exe (YARA's phone) receives the details and passes the file to YARA → YARA checks the file against malware.yar (the threat database) → Match found: result logged as "wazuh-yara: error YARA_RULE - Mimikatz" → Log Collector carries the result back to the Wazuh manager → Decoder reads the result and confirms it's a YARA match → Rule 108001 fires — Level 12 alert generated → Alert visible on Wazuh dashboard
Confirmed Working
- YARA correctly identified test files containing Mimikatz strings
- Alert Rule 108001 — Yara scan MATCH — Mimikatz confirmed firing in Wazuh
- False positives from temporary Windows system files noted and understood — expected behaviour, not a problem
- Integration deployed through the existing GitHub CI/CD pipeline for YARA rule management
What This Means in Practice
This integration adds a content-based detection layer on top of the existing behaviour-based detection rules. The existing rules detect what processes are running and what they're doing. YARA detects what's inside a file the moment it appears on the machine — before it even runs. Together they cover two different angles of the same threat.