wazuh-malware-detection v1.0A

Immutable. This exact content never changes and is served at /api/v1/blob/89134dd6d2f83baf.

---
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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.
7. **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 — role `attacker` only 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_case` severity when multiple sources corroborate.
- `add_finding`: source(s), object, corroboration, spread, verdict and recommended containment.