Building Wazuh-AFD (Anti-Forensics Detection & Automated Active Response Framework)

Executive Summary & Problem Statement

Executive Summary:

This engineering manual provides a comprehensive, step-by-step blueprint for building Wazuh-AFD (Anti-Forensics Detection): an enterprise-grade detection and automated active response framework. Designed for cybersecurity students, junior analysts, and security engineers, this guide bridges the gap between passive log collection and active defense by detailing every configuration file, telemetry source, custom rule, and automated mitigation script from zero to end.

The Problem Statement:

In modern cybersecurity operations, endpoint detection and response (EDR) solutions and Security Information and Event Management (SIEM) systems excel at capturing initial access, lateral movement, and persistence mechanisms. However, a critical blind spot persists during post-compromise stages: threat actor anti-forensics and evasion tactics.

Get Muhammad Usman’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Sophisticated attackers routinely execute clean-up operations before disconnecting from a compromised host. These tactics include:

• Clearing Windows Security Event Logs (e.g., via wevtutil cl Security) to destroy authentication traces, privilege escalation artifacts, and credential access records (MITRE ATT&CK T1070.001).
• Wiping staging artifacts, custom scripts, and payloads from the file system using native shell commands (Remove-Item or del) (MITRE ATT&CK T1070.004).
• Exploiting human response latency: In traditional architectures, a SIEM acts purely as a passive observer, generating alerts that require manual triage. By the time a human analyst reviews the logs, the adversary has already wiped the evidence and blinded the defenders.

The Objective: Wazuh-AFD

To solve this challenge, Wazuh-AFD (Anti-Forensics Detection) is engineered as a closed-loop defense framework. It combines deep endpoint telemetry streaming (Sysmon and PowerShell logs), advanced multi-event SIEM correlation rules, and automated active response scripts to detect, correlate, and contain anti-forensics campaigns instantaneously without human latency.

Section 1: End-to-End Architecture & Lab Topology

To capture evasive attacker behavior, a robust telemetry pipeline is deployed across both the endpoint and the SIEM server.

1. Architectural Components

• Victim Endpoint (Windows 11):
• Wazuh Agent: Transmits OS telemetry and logs securely to the central server.
• Microsoft Sysmon (System Monitor): Captures high-fidelity process creation, command-line arguments, and image loads (Sysmon Event ID 1).
• PowerShell Logging: Captures script block execution and command activity.
• File Integrity Monitoring (FIM): Real-time monitoring of sensitive staging directories (C:\wazuh-scripts).
• SIEM Server (Wazuh Linux Server):
• Central analysis engine responsible for parsing logs, evaluating custom detection rules, executing multi-event correlation logic, and triggering active response actions.

Architecture Diagram

2. MITRE ATT&CK Framework Mapping

• T1070.001: Indicator Removal on Host: Clear Windows Event Logs.
• T1070.004: Indicator Removal on Host: File Deletion.

Section 2: Phase 1 — Windows 11 Wazuh Agent Telemetry & Log Collection Configuration

Before writing detection rules, the Windows 11 endpoint must be configured to stream Sysmon, PowerShell, and File Integrity Monitoring (FIM) telemetry to the server.

1. Locating the Agent Configuration File

On your Windows 11 endpoint, the agent configuration is stored at: C:\Program Files (x86)\ossec-agent\ossec.conf

2. Adding Event Channel and FIM Block Definitions

To track real-time activity and modifications within your designated threat staging workspace, you define your custom directory paths directly inside the ⁠<syscheck>⁠ section of your Windows agent configuration file (⁠C:\Program Files (x86)\ossec-agent\ossec.conf⁠):

 
   <!-- File integrity monitoring -->
  <directories check_all="yes" realtime="yes">your directory path here</directories>
 

 

Open ossec.conf in an editor running as Administrator and ensure your configuration includes the following three critical telemetry blocks:

<!-- ========================================== -->
  <!-- 1. Security Event Channel Log Collection    -->
  <!-- ========================================== -->

  <localfile>
    <location>Security</location>
    <log_format>eventchannel</log_format>
  </localfile>

<!-- ========================================== -->
  <!-- 2. Sysmon Event Channel Log Collection     -->
  <!-- ========================================== -->
  <localfile>
    <location>Microsoft-Windows-Sysmon/Operational</location>
    <log_format>eventchannel</log_format>
  </localfile>


  <!-- ========================================== -->
  <!-- 3. PowerShell Operational Log Collection   -->
  <!-- ========================================== -->
  <localfile>
    <location>Microsoft-Windows-PowerShell/Operational</location>
    <log_format>eventchannel</log_format>
  </localfile>
  <!-- ========================================== -->
  <!-- 4. System Log Collection   -->
  <!-- ========================================== -->
  <localfile>
    <location>System</location>
    <log_format>eventchannel</log_format>
  </localfile>

3. Restarting the Wazuh Agent Service

Whenever changes are made to the agent’s ossec.conf, restart the Windows service to apply them:

1. Open PowerShell as Administrator.
2. Run the restart command:

Restart-Service -Name WazuhSvc

Section 3: Phase 2 — Custom Detection Engineering (local_rules.xml)

Detection engineering requires authoring custom XML rules on the Wazuh Server to catch specific attacker signatures and evasion patterns.

1. Deploying Custom Rules on the Wazuh Server

1. Log into your Wazuh Server terminal.
2. Open the custom rules file using nano:

sudo nano /var/ossec/etc/rules/local_rules.xml

<group name="windows, anti_forensics, wazuh_afd,">
  <!-- ======================================================== -->
  <!-- Wazuh-AFD: Custom Anti-Forensics Rules                    -->
  <!-- ======================================================== -->
<rule id="100001" level="12">
    <if_group>windows</if_group>
    <field name="win.system.eventID">1102</field>
    <description>Wazuh-AFD: Windows Security Audit Log Cleared (Anti-Forensics)</description>
    <mitre>
      <id>T1070.001</id>
    </mitre>
  </rule>
  <rule id="100002" level="10">
    <if_group>windows</if_group>
    <field name="win.system.eventID">1</field>
    <match>Remove-Item</match>
    <description>Wazuh-AFD: Command-Line File Deletion Detected (Anti-Forensics T1070.004)</description>
    <mitre>
      <id>T1070.004</id>
    </mitre>
  </rule>
<rule id="100003" level="14" frequency="2" timeframe="60">
    <if_matched_sid>100001</if_matched_sid>
    <if_matched_sid>100002</if_matched_sid>
    <description>Wazuh-AFD: Critical Multi-Stage Anti-Forensics Campaign Detected (Log Clearing + Artifact Deletion)</description>
    <mitre>
      <id>T1070.001</id>
      <id>T1070.004</id>
    </mitre>
  </rule>
</group>

2. Validating and Restarting the Wazuh Manager

Before applying changes live, test the configuration syntax to prevent daemon failures:

sudo /var/ossec/bin/wazuh-analysisd -t
sudo systemctl restart wazuh-manager

Section 4: Phase 3 — Automated Active Response Integration

To transform Wazuh from a passive alerting system into an active defense platform, configure an automated response that triggers when Rule 100003 fires.

1. Server-Side Active Response Configuration

1. Open the primary server configuration file:

sudo nano /var/ossec/etc/ossec.conf

Scroll to the <active-response> section and add the command block and rule mapping:

<command>
  <name>afd-incident-response</name>
  <executable>afd-response.bat</executable>
  <expect></expect>
  <timeout_allowed>no</timeout_allowed>
</command>

<active-response>
  <command>afd-incident-response</command>
  <location>local</location>
  <rules_id>100003</rules_id>
</active-response>

Active response section added in ossec.conf in wazuh manager

Save, exit, and restart the Wazuh manager:

sudo systemctl restart wazuh-manager

2. Deploying the Endpoint Response Script (afd-response.bat)

On your Windows 11 endpoint, create the local script that executes automatically upon a critical alert.

1. Open PowerShell as Administrator on Windows 11.
2. Run the following deployment block:

$ScriptPath = "C:\Program Files (x86)\ossec-agent\active-response\bin\afd-response.bat"
$ScriptContent = @"
@echo off
echo [%DATE% %TIME%] WAZUH-AFD: Critical Anti-Forensics Campaign Detected. Initiating Local Safeguards. >> C:\wazuh-scripts\containment_log.txt
echo Emergency containment triggered by Rule 100003. >> C:\<your directory path here>\containment_log.txt
"@
Set-Content -Path $ScriptPath -Value $ScriptContent

Restart the Wazuh agent service:

Restart-Service -Name WazuhSvc

3. Operational Benefits of Active Response

• Eliminates Human Latency: Automatically executes endpoint mitigation near real-time a multi-stage attack is correlated.
• Maintains Audit Trails: Appends secure, timestamped logs to C:\monitored directory added in FIM\containment_log.txt for incident response reporting.

active response text file created in the FIM directory getting monitored

• Closes the Loop: Converts the SIEM into a self-defending architecture capable of automated containment.

Section 5: Phase 4 — Live Attack Simulation & Verification Testing

Test the complete pipeline by simulating an attacker clearing audit tracks and deleting staging artifacts.

Step 1: Execute the Attack Chain on Windows 11

Open PowerShell (Administrator) and run the commands back-to-back:

# Stage 1: Clear the Windows Security Event Log
wevtutil cl Security

# Stage 2: Delete staging artifact via fresh process execution
powershell.exe -Command "Remove-Item 'C:\wazuh-scripts\test-artifact.txt' -Force -ErrorAction SilentlyContinue"

test from agent machine

Step 2: Verify Server Alerts

1. Switch to the Wazuh Server terminal.
2. Check for individual rule firing (100002) and correlation rule firing (100003):

sudo grep "100002" /var/ossec/logs/alerts/alerts.log
sudo grep "100003" /var/ossec/logs/alerts/alerts.log

rules triggered in wazuh manager

Step 3: Verify Active Response Containment

1. Return to the Windows 11 endpoint.
2. Inspect the generated containment log by running this command in powershell:

Get-Content "C:\wazuh-scripts\containment_log.txt"

containtment logs in the file created by active response

Section 6: Phase 5 — Enterprise Scaling & Production Best Practices

Deploying this architecture in a live enterprise environment requires adapting lab practices for production scale:

1. Broadening Coverage with Wildcards: Instead of static paths like C:\wazuh-scripts, enterprise FIM configurations leverage wildcards (*) and environment variables (%UserProfile%, %SystemRoot%) to monitor high-risk staging directories across every user profile simultaneously (e.g., C:\Users\*\AppData\Local\Temp\*).
2. Out-of-Band Log Streaming: While attackers can execute local log wipes (wevtutil cl), enterprise architecture mitigates this by streaming telemetry in real-time to an immutable, centralized SIEM or WORM (Write Once, Read Many) storage tier where threat actors hold no administrative privileges.
3. Centralized Policy Orchestration: Rather than configuring endpoints manually, enterprise rules and FIM policies are deployed at scale using Wazuh Agent Groups, Active Directory Group Policy Objects (GPO), or automation tools like Ansible and Microsoft Intune.

Conclusion

You have successfully engineered, configured, and tested Wazuh-AFD from zero to end. By establishing deep endpoint telemetry, writing custom detection rules, configuring multi-event SIEM correlation, and deploying automated active response scripts, you have built a professional, portfolio-grade detection project ready for demonstration on technical blogs or resume highlights!

About the Author

Muhammad Usman

Wazuh Ambassador at Wazuh

Student at Riphah International University, Faisalabad

For the Wazuh website reference:

You can explore more about the platform’s core capabilities on the official Wazuh Website.

For the Wazuh Ambassador program reference:

This project was developed and published as part of my contributions to the Wazuh Ambassador Program.