Request for Guidance: Wazuh Detection Lab for Lateral Movement, LotL, DNS Tunneling, AMSI Bypass, and Supply-Chain Defense

[whoami]

Hello Wazuh team,

I am building a detection engineering lab in Wazuh and want to implement several realistic attack scenarios using custom decoders, correlation rules, Zeek log integration, active response, and MISP enrichment. I found Wazuh’s active response framework useful for automated containment, and I also saw Wazuh’s PsExec detection example, which is a good reference for my lateral movement scenario.

I would appreciate guidance, examples, or best practices for structuring the rules and integrations below:

1. Lateral Movement via PsExec

I want Wazuh to detect PsExec execution on a Windows host using Event ID 4688 and/or related service creation artifacts, then correlate this with Zeek conn.log to confirm traffic to a critical subnet such as 192.168.1.0/24. If the source IP is confirmed and matches a threat-intelligence hit in MISP, I want to trigger an active response that blocks the source IP using firewall-drop. Wazuh already supports active response scripts for automated mitigation, which seems suitable for this workflow.

2. Living-off-the-Land (LotL) Activity

I want to detect suspicious use of built-in tools such as wmic.exe, powershell.exe, or cmd.exe, especially when a parent process spawns more than three child processes within 10 seconds. I also want to correlate these events with Zeek http.log to look for possible C2 traffic and enrich the alert with MISP TTP intelligence. If possible, I would like to isolate the host using a Wazuh active response workflow after threshold-based detection.

3. DNS Tunneling / Exfiltration

I want to detect DNS tunneling patterns such as long subdomains, base64-like labels, or unusually high query volume. The detection should correlate Wazuh alerts with Zeek dns.log, especially when a domain exceeds 1000 queries per minute and is not in an allowlist. If the domain is known malicious in MISP, I want to trigger a domain-blocking response. I am looking for advice on whether this is best implemented as a custom decoder, a custom rule, or a combination of both.

4. PowerShell AMSI Bypass / Fileless Malware

I want to detect PowerShell AMSI bypass indicators such as amsiInitFailed or Bypass-Amsi in PowerShell logs. I also want to correlate these events with Zeek conn.log to determine whether there is outbound C2 activity, then quarantine the process using a Wazuh response action. Since Wazuh supports custom rules and response automation, I would like recommendations on the best place to implement this detection logic.

5. Supply Chain Attack via Signed Malware

I want to monitor C:\Program Files for newly dropped executables, validate file hashes, and flag binaries that are unsigned or not in an allowlist. I also want to enrich the verdict with MISP and VirusTotal-style hash intelligence before quarantining the binary with active response. If anyone has a working example for file integrity monitoring plus hash-based reputation checks, I would appreciate it.

What I’m Looking For

Specifically, I would like help with:

• Recommended Wazuh decoders and rules for each scenario.

• How to correlate Wazuh alerts with Zeek conn.log, dns.log, and http.log.

• Best practices for using MISP enrichment from within Wazuh.

• Examples of active response actions such as firewall-drop, host isolation, domain blocking, and quarantine.

• Any sample local_rules.xml, decoder XML, or integration scripts that follow a clean structure.

Desired Outcome

My goal is to build a modular detection setup in Wazuh that can:

• Detect the attack technique quickly.

• Correlate endpoint and network telemetry.

• Enrich alerts with threat intelligence.

• Trigger an automated containment response.

If anyone has examples, references, or advice on how to implement these scenarios cleanly, I would really appreciate it.

[hasitha.u...@wazuh.com]

Hi whoami

Thank you for sharing these detailed detection-engineering use cases. The overall approach you described is valid, and the recommended structure is to keep the implementation modular: endpoint telemetry, Zeek network telemetry, enrichment, and active response should be handled as separate stages, with automated containment triggered only after a higher-confidence correlation or enrichment result.

For the Zeek integration, we recommend ingesting Zeek logs in JSON format and collecting them with the Wazuh agent or manager using <log_format>json</log_format>. Zeek logs such as conn.log, dns.log, and http.log can be generated in JSON and placed under /opt/zeek/logs/current, which makes them easier to parse and use in Wazuh rules. In most cases, custom rules are enough; custom decoders are only necessary if the logs are not JSON or if you need specific field normalization.
Ref: https://wazuh.com/blog/network-security-monitoring-with-wazuh-and-zeek/

For the PsExec lateral movement scenario, we recommend combining Windows/Sysmon artifacts with Zeek network evidence. Useful endpoint indicators include service creation, PSEXESVC, PsExec-related registry activity, named pipes, and process creation events. Wazuh already has a PsExec detection example that can be used as a baseline, and you can extend it with additional correlation against Zeek conn.log for SMB/RPC traffic toward sensitive subnets.
Ref: https://wazuh.com/blog/detecting-psexec-usage-with-wazuh/

For Living-off-the-Land activity, detecting suspicious executions of tools such as powershell.exe, cmd.exe, wmic.exe, mshta.exe, rundll32.exe, and regsvr32.exe is a good starting point. For the “more than three child processes within 10 seconds” condition, Wazuh rules can use correlation options such as frequency, timeframe, if_matched_sid, and same_field. This is suitable for detecting repeated or burst behavior from the same parent process or host.
Ref: https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html

For DNS tunneling, the best approach is usually a combination of Zeek dns.log collection and Wazuh custom rules. You can create rules for long subdomains, encoded-looking labels, suspicious query types, and high query volume. If you ingest Zeek DNS logs as JSON, a custom decoder is usually not required; focus first on custom rules and allowlist logic. For domain blocking, use a custom Active Response script that updates your DNS sinkhole, RPZ zone, firewall, proxy, or another enforcement point. Wazuh custom Active Response scripts can be written in any language and triggered by rule ID, level, or group.
Ref: https://documentation.wazuh.com/current/user-manual/capabilities/active-response/custom-active-response-scripts.html

For PowerShell AMSI bypass and fileless malware, enable PowerShell Script Block Logging and collect the Microsoft-Windows-PowerShell/Operational channel. Then create rules for strings such as amsiInitFailed, Bypass-Amsi, AmsiUtils, and other suspicious script block content. Wazuh supports collecting specific Windows event channels through the agent configuration, including PowerShell logs.
Ref: https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/use-cases.html

For the supply-chain / signed-malware scenario, use Wazuh File Integrity Monitoring on sensitive directories such as C:\Program Files. FIM can monitor file creation, modification, and deletion, and it stores checksums and file attributes for comparison. You can then create custom FIM rules for newly dropped .exe, .dll, or script files and enrich the file hash using VirusTotal-style or MISP-based reputation checks before taking action. Wazuh documentation includes FIM custom rules and a malware detection/removal workflow using VirusTotal integration as a useful reference pattern.

For MISP enrichment, the recommended implementation would be a custom integration using the Wazuh Integrator framework. Wazuh Integrator supports external APIs and alerting tools, and custom integrations can be filtered by rule ID, group, alert level, or event location. A clean pattern is:

Raw Wazuh alert
→ custom MISP integration
→ normalized enrichment result
→ final high-confidence Wazuh rule
→ Active Response

This avoids triggering containment from weak indicators and gives you a clear audit trail for why a response action was executed.
Ref: https://documentation.wazuh.com/current/user-manual/manager/integration-with-external-apis.html

For Active Response, built-in scripts such as firewall-drop can be used where appropriate, while actions such as host isolation, domain blocking, and file quarantine usually require custom scripts. Wazuh Active Response can execute commands based on rule ID, alert level, or rule group, and custom scripts can receive the alert context and perform the required containment action.

In summary, the recommended design would be:

1. Collect Windows, Sysmon, PowerShell, FIM, and Zeek telemetry.
2. Create separate custom rules for endpoint and network detections.
3. Use Wazuh rule correlation for local patterns such as thresholds and repeated events.
4. Use custom integrations for MISP enrichment.
5. Write enrichment results back in a normalized format.
6. Trigger Active Response only from final high-confidence rules.

This modular approach should make the lab easier to maintain, test, tune, and expand as you add more attack scenarios.

References:

• Network security monitoring with Wazuh and Zeek.
• Detecting PsExec usage with Wazuh
• Wazuh rule correlation syntax.
• Wazuh Integrator and external API integration.
• Wazuh Active Response documentation.
• Wazuh File Integrity Monitoring and VirusTotal workflow