Skill v1.0.0
currentAutomated scan100/100version: "1.0.0" name: wazuh-malware-detection description: Interpret Wazuh malware signals — rootcheck, VirusTotal and ClamAV integrations, Microsoft Antimalware events, Sysmon detections and suspicious binaries — and turn them into enrichment and containment hand-offs; use for any malware, rootkit or suspicious-binary alert. allowed-tools: get_wazuh_alerts search_security_events get_case search_cases update_case add_entities add_finding link_mitre metadata: category: investigation display_name: Wazuh Malware Detection standards: [mitre-attack, nist-800-61r3, nist-csf-2, cis-v8-1] version: "1.0"
Wazuh Malware Detection
Wazuh has no single malware engine; it aggregates several sources. Know which one fired, because their reliability differs.
Sources (stock ruleset)
| Source | Rules / group | Reliability notes | |
|---|---|---|---|
| VirusTotal integration (FIM hash lookups) | group virustotal; rule 87105 (level 12, engines detected the file), rule 87104 (level 3, no positives), rule 87103 (level 3, not in VT database), rule 87101 (level 3, API rate limit), rule 87102 (level 3, check credentials) | Good signal when many engines agree (virustotal.positives); "not in database" on a new executable in a temp path is itself suspicious | |
| Rootcheck | group rootcheck; rule 510 (level 7, host-based anomaly), rule 513 (level 9, Windows malware detected), rule 518 (level 9, Windows adware/spyware), rule 521 (level 11, possible kernel level rootkit), rule 519 (level 7, vulnerable web application found) | Signature/heuristic checks; rule 510 is a parent — read the child or full_log for the specific finding. Known false positives on some kernels/containers | |
| ClamAV (if deployed) | group virus; rule 52502 (level 8, "ClamAV: Virus detected") | Signature-based, good for known malware on Linux file servers | |
| Microsoft Antimalware / Defender events | group mse; rule 7703 (level 5, error event) | Only if the Defender event channel is collected | |
| Sysmon detections | groups sysmon_eid1_detections, sysmon_eid3_detections, sysmon_eid7_detections, sysmon_eid8_detections, sysmon_eid10_detections, sysmon_eid11_detections, sysmon_eid13_detections | Behavioural. Examples: rule 92213 (level 15, executable dropped in a folder commonly used by malware), rule 92104 (level 15, suspicious binary created network connection), rule 92900 (level 12, LSASS accessed with read permissions), rule 92400 (level 12, possible code injection on explorer.exe) | |
| Office 365 | rule 91700 (level 14, detected malware in file), rule 91556 (level 12, phishing and malware events from Exchange Online Protection / Defender) | Cloud mailbox/file detections |
YARA is not in the stock ruleset — it requires a custom active-response/integration script plus custom rules (e.g. custom rule 100300 for a YARA match). Don't claim YARA coverage unless you see such alerts.
Procedure
- Identify the source and the object: file path (
syscheck.path,virustotal.source.file,
data.win.eventdata.targetFilename), hash (virustotal.source.sha1, syscheck.sha256_after), process image (data.win.eventdata.image), parent process.
- Corroborate across sources in the same window on the same agent:
get_wazuh_alerts agent_id="<id>" rule_groups=["virustotal","rootcheck","virus","sysmon","syscheck"] timestamp_start="now-24h". One engine alone is weak; FIM add + VirusTotal hit + outbound connection is strong.
- Linux heuristics: executables in
/tmp,/var/tmp,/dev/shm, hidden dot-directories, names
mimicking kernel threads (kworkerd, kdevtmpfsi), high CPU with outbound connections to mining pools. Windows: executables in AppData, ProgramData, Temp; rundll32/regsvr32 loading user-writable DLLs; unsigned binaries in System32.
- Process and network context: running processes and listening ports come from syscollector — if
you are investigation, check them with your inventory tools; otherwise hand off to investigation.
- Reputation: hashes, domains and IPs go to threat-intel. If you are threat-intel, run
check_ioc_reputation; everyone else hands off to threat-intel.
- Spread: search the same hash or file name across the fleet with
search_security_events
(query = the hash or filename) before concluding it's a single host.
- Containment: never act yourself. Hand off to response-planner with the evidence — typical options
are quarantine_file (needs agent_id + file_path), kill_process (agent_id + process_id) and, for confirmed compromise, isolate_host.
False positives
Security tools themselves (EDR, backup agents, scanners), admin tooling (PsExec, Sysinternals), developer build output in temp directories, and rootcheck on hardened/containerized kernels. Record why you judged a hit benign.
Output
add_entities: file (path), hash, process, and any remote IP/domain — roleattackeronly with
evidence.
link_mitre: e.g. T1204 (User Execution), T1496 (Resource Hijacking), T1055 (Process Injection),
T1003.001 (LSASS Memory) — only what the evidence supports.
update_caseseverity when multiple sources corroborate.add_finding: source(s), object, corroboration, spread, verdict and recommended containment.