Teaching Wazuh to watch Windows Defender

Introduction

Hello, my name is Christopher Brown Johnson, I am pursuing my CompTIA Security+ through the wonderful program Triple Ten. I have never studied anything within the field but over the last few months have learned a tremendous amount of knowledge within this field thanks to this program.

For this sprint, I added a new log source to my SIEM: Windows Defender's own detection events from ad01, ingested directly into Wazuh using the agent's built-in event channel log collector. Before this, my deployment had no visibility into what Defender was catching on that endpoint; if malware got flagged, the SIEM would never know. I closed that gap, then ran three experiments to see how different types of Defender detections—a straightforward malware signature, a potentially unwanted application, and real-time behavioral analysis— actually show up (or don't) in Wazuh.

Setup

The Modification

The modification that I chose was configuring the Wazuh agent already running on ad01 to collect the Microsoft-Windows-Windows Defender/Operational event log channel natively (via a localfile entry using the event channel log format in ossec.conf), so that Windows Defender detections, specifically Event ID 1116, flow into Wazuh with full file path details. The baseline deployment had no native AV visibility at all, so this was about closing a real blind spot rather than adding a nice-to-have. This route also meant no separate Winlogbeat install (which at first I believed was the correct route), no manual cert configuration, and no version matching against the Wazuh indexer. The agent already has a trusted, authenticated channel back to the manager, so this new log source just rides along on that. This was appealing to me due to the fact that identifying these paths would give greater light into where the harm is coming from.

Walkthrough

-First, confirmed the Wazuh agent was already running on ad01:
Get-Service WazuhSvc
-Then added a new localfile block to ossec.conf (backing up the original first):
-Restarted the agent to pick up the config change:
Restart-Service WazuhSvc

![[Modification 1.png]]
![[Modification 2.png]]

Experiment #1

**

EICAR Standard Antivirus Test

Why: Confirm the whole pipeline works end-to-end with the simplest possible detection before trusting more complex results in Experiments #2 and #3.

How: Created the standard EICAR test string as a .txt file on ad01 with real-time protection enabled to trigger a baseline Defender detection.

Expected Outcome: Event ID 1116 in the Microsoft-Windows-Windows Defender/Operational channel, mapped to Wazuh's built-in 0600-win-wdefender_rules.xml ruleset (~level 12). Specific fields expected: threatName = EICAR test file signature, severityName = Severe, detectionSource = Real-Time Protection, path = full path to EICAR.txt.

![[EICAR TEST.png]]
![[EICAR Test 3.png]]
![[EICAR Test 3.5.png]]
![[EICAR Test Wazuh.png]]

Experiment #2

**

Potentially Unwanted Application (PUA) Detection

Why: Test whether a lower-severity PUA flag is actually distinguishable from a full malware detection in Wazuh or whether it just looks identical to Experiment #1.

How: Enabled PUA protection on ad01 (Set-MpPreference -PUAProtection Enabled) and ran Microsoft's official PUA demonstration file.

Expected Outcome: Still Event ID 1116 (same as Experiment #1); the event ID alone shouldn't distinguish this from malware. The differentiator should be in the fields: category = PotentiallyUnwantedApplication/PUA (vs. Trojan/Virus), severityName = Low/Moderate (vs. Severe), and a correspondingly lower Wazuh rule level than the EICAR alert.

When running this test, there were no notifications or anything that was found when looking through Defender or Wazuh.

Experiment #3

 ###  Behavior Monitoring Demonstration

Why: Test a fundamentally different detection mechanism (behavior/heuristics vs. static signature) and see whether PowerShell-based execution logging offers a second, independent view of the same activity.

How: Ran Microsoft's official Behavior Monitoring demonstration command via an elevated PowerShell session on ad01:

powershell.exe -NoExit -Command "powershell.exe hidden 12154dfe-61a5-4357-ba5a-efecc45c34c4"

Expected Outcome: Still Event ID 1116 from Defender, but with detectionSource = Behavior Monitoring (instead of Real-Time Protection) and threatName prefixed "Behavior:Win32/..." proving the detection engine changed even though the event schema didn't. Separately, if PowerShell Script Block Logging is enabled, expect Event ID 4104 in Microsoft-Windows-PowerShell/Operational with the raw command text as a second independent data point on the same activity.**

![[Behavior Monitoring 1 3.png]]
![[Behavior Monitoring 2.png]]

Conclusion

What I found:

• Experiment 1 (EICAR): Wazuh was able to identify that Defender had done its job and showed details of where the file path came from.
• Experiment 2 (PUA): I found that Defender had no communication with the PUA suggesting that it wasn't a notable threat.
• Experiment 3 (Behavior Monitoring): Wazuh was able to identify that Defender had done its job and showed details of where the file path came from. Even identifying that in this experiment Event ID 1116 wasn't the only ID detected.

Mistakes Made

Modification 1
-There was no need in using winlogbeats, the only thing needed was to edit the already existing ossec.conf file
-Tried loading an entire logging system that was unnecessary

Experiment 1
-Did not use Power Shell at first and there were no hits in Wazuh
-Changed to powershell then wazuh got notified

Experiment 2
-When trying to download https://www.amtso.org/feature-settings-check-potentially-unwanted-applications/ nothing happened.

Advice on avoiding mistakes

My best advice on how to avoid mistakes would be patience. While configuring the modification, there were a few times when I didn't recognize that I was too high in the line of code or the simple task of verifying that each space is the correct distance. ALWAYS double-check what you typed was the correct line.

The coolest thing I learned

I learned that the amount of information that one can gain from exploring Wazuh is almost infinite. The fact that simply changing the ossec.conf file to recognize a specific set of information can allow you to gain knowledge of the threat, where it comes from, what was done to protect the system, and the ability to teach the system how to recognize these threats brings me so much insight on how enormous this CyberSecurity field truly is.

One piece of advice

My one piece of advice that I will stress over and over again is to be patient, assess the situation, and make sure that you are double-checking all of your steps so you don't have to start over from the beginning. This is something that helped me once the wheels started to turn.

My favorite resource

I am a big advocate of using Reddit, as well as DOT, which both guided me and gave me the information needed to complete this sprint.

Thank you (gratitudes)!

I would like to thank Jean Forbe for helping me identify the issues in my plan, DOT for helping me organize the plan and have a well-rounded idea of how to create this blog, and I would like to thank every single instructor in the Triple Ten program who has checked my sprints and given me feedback to become a better analyst.

References

1.

Wazuh. (n.d.). Windows Defender Logs Collection. https://documentation.wazuh.com/current/user-manual/capabilities/malware-detection/win-defender-logs-collection.html Official Wazuh documentation covering the eventchannel log format used to add the Microsoft-Windows-Windows Defender/Operational channel directly to the agent's ossec.conf, including a sample alert used as a reference point for expected rule structure.

2.

EICAR. (n.d.). Anti-Malware Testfile. https://www.eicar.org/download-anti-malware-testfile/ The standard, harmless test string recognized by virtually all antivirus engines as "malware," used to trigger a baseline Defender detection without using real malicious code.

3.

Microsoft. (n.d.). Microsoft Defender for Endpoint — Demonstration Scenarios. https://learn.microsoft.com/en-us/defender-endpoint/defender-endpoint-demonstrations Index page of official Microsoft demonstration scenarios, used to select the PUA and Behavior Monitoring demonstrations for Experiments 2 and 3.

4.

Microsoft. (n.d.). Behavior Monitoring Demonstration. https://learn.microsoft.com/en-us/defender-endpoint/demonstration-behavior-monitoring Official walkthrough with the specific PowerShell command used to simulate behavior-based detection in Experiment 3.