How to Monitor Windows Event Logs Using Wazuh

Windows Event Logs are one of the most valuable sources of security and operational data in a Microsoft environment.

These logs provide a detailed audit trail that helps administrators, security analysts, and incident responders understand what is happening across their infrastructure.

Monitoring Windows Event Logs is critical for both security and operations.

From a security perspective, event logs can reveal indicators of compromise such as failed login attempts, privilege escalation activities, unauthorized account creation, suspicious PowerShell execution, and malware detections.

Operational teams use the same logs to troubleshoot system failures, identify application issues, and monitor overall system health.

This is where Wazuh becomes particularly valuable. Wazuh enables organizations to collect, centralize, analyze, and correlate Windows Event Logs from multiple systems in real time.

Rather than manually reviewing logs on individual servers or workstations, security teams can monitor all Windows events through a single platform.

Wazuh also enriches logs with threat intelligence, detection rules, and MITRE ATT&CK mappings to help identify suspicious activity faster.

By using Wazuh for Windows Event Log monitoring, organizations can:

• Centralize logs from Windows servers and workstations
• Detect threats in real time
• Improve incident response capabilities
• Meet compliance and auditing requirements
• Gain visibility into authentication, system, and application events
• Correlate Windows events with activity from other security data sources

In this guide, you will learn how Windows Event Logs work, how Wazuh collects and analyzes them, how to configure Windows Event Log monitoring, and how to use Wazuh to detect suspicious activity across your Windows environment.

Understanding Windows Event Logs

What Are Windows Event Logs?

Windows Event Logs are structured records generated by the Windows operating system and installed applications.

These logs capture information about system activity, user actions, software behavior, security events, and hardware operations.

The Windows logging system acts as a centralized repository where events are recorded whenever specific actions occur.

For example, when a user logs into a system, a service starts, an application crashes, or malware is detected by Windows Defender, an event is generated and stored within the appropriate event log.

Administrators can view these logs using Event Viewer, while security platforms such as Wazuh can collect and analyze them automatically.

According to Microsoft, Windows Event Logs provide the primary mechanism for recording operating system, security, and application activity across Windows environments.

How Windows Records System and Application Activity

Windows uses the Event Log service to collect and store events generated by:

• The operating system
• Security auditing components
• Applications and services
• Device drivers
• Microsoft Defender
• PowerShell
• Third-party software

Each event typically contains:

• Event ID
• Timestamp
• Event source
• Severity level
• User account information
• Computer name
• Detailed event description

These details provide valuable context during investigations and troubleshooting activities.

Main Windows Event Log Categories

Windows organizes events into several primary log categories.

Application Logs

Application logs contain events generated by software installed on the system.

Examples include:

• Application crashes
• Database errors
• Service failures
• Software updates
• Application-specific warnings

These logs are frequently used by administrators to diagnose software-related issues.

Security Logs

Security logs contain events generated by Windows auditing policies.

Examples include:

• User logins and logoffs
• Failed authentication attempts
• Account lockouts
• Group membership changes
• Privilege assignments
• Audit policy modifications

Security logs are often the most important source for threat detection and compliance monitoring.

System Logs

System logs record events generated by the Windows operating system and hardware components.

Examples include:

• System startup and shutdown events
• Driver failures
• Service start and stop events
• Hardware issues
• Resource exhaustion warnings

These logs help identify operating system and infrastructure problems.

Setup Logs

Setup logs capture events related to operating system installation and configuration changes.

Examples include:

• Windows installation events
• Feature upgrades
• Patch installations
• System configuration changes

These logs are useful when troubleshooting deployment and upgrade issues.

Forwarded Events

Forwarded Events contain logs received from other Windows systems through Windows Event Forwarding (WEF).

Organizations often use WEF to aggregate logs from multiple systems into a centralized location before sending them to a SIEM platform.

Microsoft recommends Windows Event Forwarding as a scalable approach for collecting security events across enterprise environments.

Common Security-Relevant Events

Certain Windows events are particularly valuable for detecting threats and investigating incidents.

User Logons and Logoffs

Authentication events help security teams track who accessed systems and when access occurred.

Important Event IDs include:

• 4624 – Successful logon
• 4634 – Logoff

These events establish a timeline of user activity during investigations.

Failed Login Attempts

Repeated authentication failures can indicate:

• Password spraying attacks
• Brute-force attempts
• Misconfigured services
• Unauthorized access attempts

The most common event associated with failed logins is:

• 4625 – Failed logon

Account Lockouts

Account lockout events can indicate ongoing attack activity or excessive authentication failures.

Common Event ID:

• 4740 – Account locked out

Monitoring these events helps security teams quickly identify targeted accounts.

Privilege Escalation

Attackers frequently attempt to gain elevated permissions after initial access.

Examples include:

• Administrator privilege assignments
• Group membership changes
• Elevated token usage

Important Event IDs include:

• 4672 – Special privileges assigned
• 4732 – User added to privileged group

Service Installations

Malware and attackers often install malicious services to maintain persistence.

Monitoring service creation events helps identify unauthorized software installations.

Common Event ID:

• 4697 – Service installed

Scheduled Task Creation

Scheduled tasks are frequently abused by attackers to establish persistence mechanisms.

Security teams often monitor:

• Task creation
• Task modification
• Task execution activity

These events can reveal unauthorized automation and malware activity.

Windows Defender Detections

Microsoft Defender generates events whenever malware, potentially unwanted applications, or suspicious behavior is detected.

Examples include:

• Malware detections
• Quarantine actions
• Real-time protection alerts
• Threat remediation activities

These events provide valuable endpoint security visibility and can be forwarded directly into Wazuh for centralized monitoring.

Why Use Wazuh for Windows Event Log Monitoring?

Centralized Log Collection

One of the biggest challenges in Windows environments is managing logs across multiple servers and workstations.

Wazuh solves this problem by collecting Windows Event Logs from endpoints and sending them to a centralized platform where security teams can search, analyze, and investigate activity from a single interface.

Aggregating Logs from Multiple Windows Systems

Rather than logging into individual systems to review events, Wazuh enables administrators to collect logs from:

• Windows servers
• Domain controllers
• Workstations
• Virtual machines
• Cloud-hosted Windows instances

This centralized approach improves visibility across the entire environment.

If you are already onboarding Windows systems, see our guide on How to Install a Wazuh Agent on Windows Server.

Simplifying Investigations

Centralized logging significantly reduces investigation time.

Analysts can:

• Search events across multiple hosts
• Correlate activity between systems
• Identify attack patterns
• Build incident timelines

This makes threat hunting and incident response far more efficient.

Real-Time Threat Detection

Security Event Monitoring

Wazuh continuously monitors incoming Windows Event Logs and compares them against built-in detection rules.

These rules can identify:

• Brute-force attacks
• Privilege escalation attempts
• Suspicious PowerShell activity
• Account creation events
• Malware detections

Real-time analysis helps security teams identify threats before they escalate.

Immediate Alert Generation

When suspicious activity is detected, Wazuh generates alerts automatically.

Alerts can be:

• Displayed in the dashboard
• Forwarded to external systems
• Sent to notification platforms
• Used in automated response workflows

This reduces detection and response times significantly.

Organizations using security monitoring platforms with centralized log analysis generally achieve faster threat detection and incident response compared to manual review processes.

According to IBM’s Cost of a Data Breach research, faster detection and containment are strongly associated with lower breach costs.

Compliance and Auditing Benefits

Windows Event Logs are a critical data source for many compliance frameworks.

PCI DSS

PCI DSS requires organizations to track and monitor access to network resources and cardholder data.

Windows security logs provide evidence of:

• User access
• Authentication activity
• Administrative actions

HIPAA

Healthcare organizations must maintain audit controls and monitor access to sensitive information.

Windows Event Logs help satisfy audit trail requirements for protected health information (PHI).

NIST

The NIST Cybersecurity Framework emphasizes continuous monitoring and event logging as key security controls.

Centralized Windows log monitoring supports these requirements by providing visibility into security events and system activity.

ISO 27001

ISO 27001 requires organizations to implement logging and monitoring controls to detect security incidents and maintain accountability.

Wazuh helps organizations collect and retain the audit data needed to support compliance initiatives.

Built-In Security Analytics

Beyond simple log collection, Wazuh provides advanced security analytics capabilities.

Correlation Capabilities

Wazuh can correlate events from multiple sources to identify suspicious behavior patterns.

Examples include:

• Multiple failed logins followed by a successful login
• Privilege escalation after account compromise
• Malware detection followed by suspicious network activity

These correlations help uncover attacks that might be missed when examining individual events.

For advanced detection tuning, see our guides on How to Create Custom Detection Rules in Wazuh and How to Test Wazuh Rules.

MITRE ATT&CK Mapping

Many Wazuh detection rules are mapped to the MITRE ATT&CK framework.

This helps analysts understand:

• Adversary tactics
• Attack techniques
• Potential attack progression

MITRE ATT&CK mapping also improves threat hunting and reporting capabilities.

Security Dashboards

Wazuh includes dashboards that provide visibility into:

• Authentication activity
• Endpoint security events
• Malware detections
• Compliance metrics
• Alert trends

These dashboards transform raw Windows Event Logs into actionable security intelligence that can be used by security operations teams and administrators alike.

Wazuh Architecture for Windows Event Monitoring

Understanding how Windows Event Logs move through the Wazuh platform helps administrators troubleshoot issues, optimize detection capabilities, and better understand the security monitoring process.

Wazuh uses a distributed architecture that collects, analyzes, stores, and visualizes Windows events from endpoints across the environment.

Components Involved

Several key components work together to process Windows Event Logs.

Wazuh Agent

The Wazuh Agent is installed directly on Windows endpoints and serves as the primary log collection component.

Its responsibilities include:

• Collecting Windows Event Logs
• Monitoring file integrity changes
• Gathering system inventory information
• Detecting security events
• Forwarding collected data to the Wazuh Manager

For Windows Event Monitoring, the agent uses the native Windows Event Log API to subscribe to event channels and collect events as they occur.

The agent operates with minimal system overhead, making it suitable for servers, workstations, and domain controllers.

Wazuh Manager

The Wazuh Manager acts as the central analysis engine.

It is responsible for:

• Receiving events from agents
• Decoding log data
• Applying detection rules
• Generating alerts
• Correlating security events
• Managing agent communications

When Windows events arrive, the manager processes them through decoders and rulesets that determine whether the activity is benign or potentially malicious.

Organizations that need advanced detection capabilities often customize these rules.

For more information, see How to Create Custom Detection Rules in Wazuh.

Wazuh Indexer

The Wazuh Indexer stores processed events and alerts.

Its primary functions include:

• Long-term event storage
• Event indexing
• Search optimization
• Historical analysis
• Dashboard data retrieval

The Indexer enables security teams to quickly search millions of Windows events during investigations.

Large environments may deploy multiple indexer nodes for scalability and resilience.

See How to Build a Wazuh Indexer Cluster for deployment guidance.

Wazuh Dashboard

The Wazuh Dashboard provides the user interface used to investigate and visualize collected Windows events.

Security teams can:

• Search event logs
• Review alerts
• Analyze authentication activity
• View compliance reports
• Investigate suspicious behavior
• Build custom dashboards

The dashboard transforms raw event data into actionable security insights.

How Windows Logs Flow Through Wazuh

Windows Event Monitoring follows a straightforward processing pipeline.

Event Generated on Windows Endpoint

The process begins when Windows records an event.

Examples include:

• User logons
• Failed authentication attempts
• Service installations
• Account lockouts
• PowerShell execution
• Windows Defender detections

The event is written to the appropriate Windows Event Log channel.

Wazuh Agent Collects the Event

The Wazuh Agent continuously monitors configured event channels.

When a new event appears, the agent:

• Reads the event
• Extracts relevant metadata
• Formats the data for transmission

This collection process occurs automatically and continuously.

Event Sent to Wazuh Manager

After collection, the agent securely forwards the event to the Wazuh Manager.

Communication is encrypted to help protect log integrity and confidentiality while in transit.

Rules and Decoders Analyze Data

Once received, the manager processes the event through:

• Decoders
• Detection rules
• Correlation logic
• Threat intelligence integrations

This analysis determines whether the event should generate an alert.

For example:

• Multiple Event ID 4625 failures may trigger a brute-force detection rule.
• Privileged group modifications may generate a high-severity alert.
• Malware detections may trigger immediate notifications.

Alert Stored and Visualized

Generated alerts are stored within the Wazuh Indexer and become available through the Dashboard.

Analysts can then:

• Search historical events
• Review alerts
• Investigate incidents
• Create reports
• Conduct threat hunting activities

This end-to-end pipeline provides centralized visibility into Windows activity across the organization.

Prerequisites

Before configuring Windows Event Log monitoring, verify that both your Wazuh environment and Windows endpoints meet the necessary requirements.

Wazuh Environment Requirements

Operational Wazuh Deployment

You should have a fully operational Wazuh environment that includes:

• Wazuh Manager
• Wazuh Indexer
• Wazuh Dashboard

All components should be functioning normally before onboarding Windows endpoints.

If you are still building your infrastructure, review How to Build a Wazuh Indexer Cluster for scalable deployments.

Manager Connectivity

The Wazuh Manager must be reachable from Windows endpoints.

Verify:

• DNS resolution
• Network routing
• Manager availability
• Agent registration capability

Connectivity problems can prevent log collection entirely.

Windows Endpoint Requirements

Supported Windows Versions

Wazuh supports modern Windows operating systems including:

• Windows 10
• Windows 11
• Windows Server 2016
• Windows Server 2019
• Windows Server 2022

Older operating systems may have limited support and should be tested before deployment.

For the most current compatibility information, consult the official Wazuh documentation.

Administrative Access

Administrative privileges are typically required to:

• Install the Wazuh Agent
• Modify agent configuration files
• Register endpoints
• Restart services

Without appropriate permissions, deployment and configuration may fail.

Network Requirements

Agent-to-Manager Communication

Windows agents must communicate with the Wazuh Manager using the configured communication ports.

Verify:

• Bidirectional network access
• Correct manager IP or hostname configuration
• Proper agent registration

Reliable connectivity ensures continuous event delivery and alert generation.

Firewall Considerations

Local and network firewalls should allow communication between:

• Windows endpoints
• Wazuh Manager
• Indexer nodes (if applicable)

Common issues include:

• Blocked management ports
• Restricted outbound traffic
• Network segmentation policies

If agents fail to connect, see Wazuh Agent Not Connecting to Manager? 12 Fixes That Actually Work for troubleshooting guidance.

Installing the Wazuh Agent on Windows

The Wazuh Agent must be installed on each Windows endpoint you want to monitor.

Downloading the Agent

Obtaining the Latest Agent Package

Download the latest Windows Agent directly from the official Wazuh repository.

Using the latest version helps ensure:

• Security updates
• Bug fixes
• Improved compatibility
• New features

Always verify that the agent version is compatible with your Wazuh Manager version before deployment.

Installing the Agent

GUI Installation

The graphical installer provides the easiest deployment method for individual systems.

Installation steps:

1. Launch the Wazuh Agent installer.
2. Accept the license agreement.
3. Specify the Wazuh Manager address.
4. Complete the installation wizard.
5. Start the Wazuh Agent service.

During installation, you will be prompted to enter the Manager IP address or hostname that the agent will connect to.

Silent Installation Options

For large-scale deployments, administrators often use silent installations.

Common deployment methods include:

• Group Policy
• Microsoft Endpoint Configuration Manager (SCCM)
• Intune
• PowerShell automation
• Remote management tools

Silent deployments allow hundreds or thousands of Windows endpoints to be onboarded consistently and efficiently.

Registering the Agent

Connecting the Endpoint to Wazuh Manager

Once installed, the agent must be registered with the Wazuh Manager.

Registration establishes trust between:

• The Windows endpoint
• The Wazuh Manager

After successful registration, the endpoint will begin sending telemetry and event logs.

Verifying Enrollment

You can verify successful enrollment from the Wazuh Dashboard.

Navigate to:

Agents → Summary

The newly registered Windows endpoint should appear in the agent inventory.

An active status indicates successful communication.

Confirming Agent Connectivity

Checking Agent Status

Verify that the agent is communicating properly.

On the Windows endpoint, confirm the service is running:

Get-Service Wazuh

Expected output:

Status : Running

You can also verify connectivity from the Wazuh Dashboard by checking the agent’s status.

Troubleshooting Connection Issues

Common connectivity problems include:

• Incorrect manager address
• DNS resolution failures
• Firewall restrictions
• Certificate issues
• Version mismatches
• Agent registration failures

If the agent appears disconnected or never enrolls successfully, review Wazuh Agent Not Connecting to Manager? 12 Fixes That Actually Work and How to Fix Wazuh Certificate Errors for detailed troubleshooting procedures.

Configuring Windows Event Log Collection

After installing and registering the Wazuh Agent, the next step is configuring Windows Event Log collection.

Wazuh uses the native Windows Event Log API to subscribe to event channels and forward events to the Wazuh Manager for analysis.

Understanding Eventchannel Configuration

How Wazuh Collects Windows Events

Unlike traditional text-based log files, Windows Event Logs are stored in a structured format managed by the Windows Event Log service.

Wazuh accesses these logs using the Windows Event Log API and continuously monitors configured event channels for new events.

When an event is generated:

1. Windows writes the event to an Event Log channel.
2. The Wazuh Agent detects the new event.
3. The event is collected and formatted.
4. The event is securely transmitted to the Wazuh Manager.
5. Detection rules and decoders analyze the event.
6. Alerts are generated when suspicious activity is identified.

This process occurs automatically and in near real time.

Eventchannel Basics

Windows Event Logs are monitored using the eventchannel log format within the Wazuh Agent configuration.

Each monitored channel is defined using a <localfile> block.

The basic syntax is:

<localfile>
  <location>CHANNEL_NAME</location>
  <log_format>eventchannel</log_format>
</localfile>

The <location> field specifies the Windows Event Log channel to monitor.

Default Windows Event Log Monitoring

Most Wazuh Windows deployments begin by monitoring the three primary event channels.

Security

The Security channel contains:

• User authentication activity
• Account management events
• Privilege assignments
• Audit policy changes
• Security-related system activity

This channel is typically the highest priority for security monitoring.

System

The System channel records operating system events such as:

• Service starts and stops
• Driver failures
• System restarts
• Hardware issues
• Operating system warnings

These events are valuable for operational monitoring and troubleshooting.

Application

The Application channel contains logs generated by installed applications and services.

Examples include:

• Application crashes
• Software warnings
• Database errors
• Service failures
• Application-specific alerts

Monitoring Application logs helps identify software-related issues that may impact system availability.

Reviewing Existing Agent Configuration

Location of ossec.conf

The primary Wazuh Agent configuration file is:

C:\Program Files (x86)\ossec-agent\ossec.conf

This file controls:

• Log collection settings
• Agent communication parameters
• File Integrity Monitoring
• Command execution settings
• Event Log subscriptions

Administrators should always back up this file before making modifications.

Default Monitoring Settings

Most Windows Agent installations already include default monitoring for:

• Security
• System
• Application

Reviewing the configuration confirms which channels are currently enabled.

Example Eventchannel Configuration

The following configuration enables Security Event Log monitoring:

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

Additional channels can be monitored by adding more <localfile> entries.

For advanced detection use cases, many organizations combine Event Log monitoring with How to Configure File Integrity Monitoring (FIM) in Wazuh to gain visibility into both user activity and file changes.

Restarting the Agent

Applying Configuration Changes

After modifying ossec.conf, restart the Wazuh Agent to load the new configuration.

Using PowerShell:

Restart-Service Wazuh

Or from Command Prompt:

net stop Wazuh
net start Wazuh

Verifying Successful Startup

After restarting the service:

1. Open the Services console.
2. Confirm the Wazuh service is running.
3. Verify agent status in the Wazuh Dashboard.
4. Check that new Windows events are appearing.

If the agent fails to reconnect, review Wazuh Agent Not Connecting to Manager? 12 Fixes That Actually Work for troubleshooting guidance.

Monitoring Additional Windows Event Channels

While Security, System, and Application logs provide valuable visibility, many organizations expand monitoring to include additional event channels that offer deeper security insights.

Windows Defender Logs

Microsoft Defender generates security events whenever malware or suspicious activity is detected.

Malware Detection Events

Defender logs can reveal:

• Malware detections
• Potentially unwanted applications (PUAs)
• Trojan activity
• Ransomware indicators
• Suspicious file execution

These events help security teams quickly identify endpoint threats.

Antivirus Alerts

Monitoring Defender alerts allows organizations to track:

• Threat severity
• Quarantine actions
• Scan results
• Real-time protection events

Microsoft recommends monitoring Defender Operational logs for security investigations and threat hunting.

PowerShell Operational Logs

PowerShell is commonly abused by attackers for execution, persistence, and lateral movement.

1. PowerShell Command Execution

PowerShell logs can capture:

• Script execution
• Administrative commands
• Encoded commands
• Remote PowerShell sessions

These events provide critical visibility during incident investigations.

2. Script Monitoring

Monitoring PowerShell activity helps detect:

• Malicious scripts
• Credential dumping attempts
• Reconnaissance activity
• Download-and-execute techniques

Security researchers frequently identify PowerShell abuse as a common post-exploitation technique, making these logs highly valuable for detection efforts.

Sysmon Logs

Many organizations deploy Sysmon to supplement native Windows logging.

Advanced Endpoint Visibility

Sysmon provides telemetry not available in standard Windows logs.

Examples include:

• Process execution
• Registry modifications
• Network connections
• Driver loading
• File creation activity

Process Creation Monitoring

Process creation events help analysts detect:

• Malware execution
• Suspicious command lines
• Script interpreters
• Living-off-the-land binaries (LOLBins)

Network Connection Monitoring

Sysmon can also record:

• Outbound connections
• Internal lateral movement
• Command-and-control communications
• Suspicious network activity

For additional threat detection coverage, organizations often combine Sysmon monitoring with How to Detect Ransomware Activity Using Wazuh.

Microsoft Sysinternals Sysmon is widely considered one of the most valuable Windows telemetry sources for security monitoring.

Terminal Services Logs

Remote Desktop Protocol (RDP) is a frequent attack target.

Remote Desktop Monitoring

Terminal Services logs provide visibility into:

• RDP logins
• Remote session activity
• Authentication failures
• Session disconnections

These logs are useful for detecting unauthorized remote access attempts.

Session Tracking

Organizations can use Terminal Services events to:

• Track user sessions
• Identify suspicious access patterns
• Investigate account compromise incidents

Task Scheduler Logs

Scheduled tasks are commonly used by both administrators and attackers.

Scheduled Task Creation and Execution

Task Scheduler logs can reveal:

• New task creation
• Task modifications
• Task execution
• Unauthorized persistence mechanisms

Monitoring these events helps identify attacker persistence techniques.

Example Multi-Channel Configuration

The following example enables monitoring for PowerShell Operational logs:

<localfile>
  <location>Microsoft-Windows-PowerShell/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Additional channels can be configured using the same structure.

As organizations expand visibility, they often integrate Windows logs with other telemetry sources such as How to Collect Firewall Logs in Wazuh and How to Monitor AWS CloudTrail Logs Using Wazuh to create a more comprehensive security monitoring platform.

Monitoring Security Events in Wazuh

Windows Security Logs are often the most important data source for detecting suspicious activity and investigating security incidents.

Wazuh can collect, analyze, and alert on these events in real time.

Important Windows Security Event IDs

Understanding common Event IDs helps security teams prioritize investigations and detection rules.

Authentication Events

Event ID 4624 (Successful Logon)

This event indicates a successful authentication.

Common use cases include:

• User activity tracking
• Login auditing
• Access investigations

Analysts often review these events during incident response to determine when users accessed systems.

Event ID 4625 (Failed Logon)

This event indicates an authentication failure.

Common causes include:

• Incorrect passwords
• Brute-force attacks
• Password spraying attacks
• Misconfigured applications

Repeated 4625 events are frequently used to detect credential attacks.

Event ID 4634 (Logoff)

This event records user logoff activity.

Monitoring logoff events helps build accurate user activity timelines.

Account Management Events

Event ID 4720 (User Created)

This event occurs when a new user account is created.

Security teams often investigate unexpected account creation activity because attackers commonly create backdoor accounts after gaining access.

Event ID 4726 (User Deleted)

This event records account deletion activity.

Unexpected deletions may indicate malicious attempts to remove evidence or disrupt operations.

Event ID 4732 (Group Membership Added)

This event occurs when a user is added to a security-enabled local group.

Monitoring privileged group additions is essential because attackers often seek administrative access after compromise.

Privilege Escalation Events

Event ID 4672 (Special Privileges Assigned)

This event indicates that elevated privileges were assigned during logon.

Examples include:

• Administrator access
• Backup privileges
• Security management privileges

Frequent monitoring of Event ID 4672 helps identify privileged account usage.

Policy and Audit Changes

Event ID 4719

This event indicates changes to system audit policies.

Attackers sometimes modify auditing settings to reduce visibility into their activities.

Event ID 4902

This event records changes to the per-user audit policy table.

Unexpected modifications may warrant further investigation.

Viewing Security Events in the Wazuh Dashboard

Security Monitoring Dashboards

The Wazuh Dashboard provides multiple ways to analyze security events.

Common views include:

• Authentication activity
• Security alerts
• Endpoint-specific events
• Event timelines
• Compliance reporting

These dashboards help analysts quickly identify suspicious activity.

Event Filtering Techniques

Filtering improves investigation efficiency.

Useful filters include:

• Event ID
• Username
• Hostname
• Source IP address
• Alert severity
• Time range

Examples:

win.system.eventID:4625

win.system.eventID:4672

agent.name:"DC01"

Security teams often create saved searches and dashboards for frequently investigated events, enabling faster detection and response.

For organizations that need custom detection logic, see How to Create Custom Detection Rules in Wazuh and How to Test Wazuh Rules.

Creating Custom Wazuh Rules for Windows Event Logs

While Wazuh includes hundreds of built-in detection rules for Windows Event Logs, most organizations eventually require custom rules that align with their environment, security policies, and threat landscape.

Custom rules allow security teams to detect organization-specific threats while reducing unnecessary alerts.

Why Custom Rules Are Useful

Organization-Specific Detections

Every environment is different.

For example, an organization may want to generate alerts when:

• Members are added to a specific Active Directory group
• Critical servers experience repeated login failures
• Certain PowerShell commands are executed
• Administrative accounts are used outside business hours

Custom rules enable these tailored detection scenarios.

Noise Reduction

One of the biggest challenges in security monitoring is alert fatigue.

Custom rules can help reduce noise by:

• Filtering low-value events
• Excluding known benign activity
• Prioritizing high-risk behavior
• Adjusting alert severity levels

Organizations that properly tune detection rules generally experience higher signal-to-noise ratios and more efficient investigations.

If you’re seeing excessive alerts, review How to Reduce False Positives in Wazuh.

Understanding Wazuh Rule Structure

Custom rules are defined in XML and evaluated after built-in rules.

Each rule consists of several components.

Rule IDs

Every custom rule requires a unique ID.

Best practices include:

• Using IDs above 100000
• Avoiding conflicts with existing rules
• Maintaining internal documentation

Rule IDs help identify which rule generated an alert.

Levels

The level defines alert severity.

Examples:

Higher severity levels should be reserved for events that require immediate attention.

Conditions

Conditions determine when a rule triggers.

Common conditions include:

• Event IDs
• Source IP addresses
• Usernames
• Hostnames
• Previous rule matches
• Frequency thresholds

Multiple conditions can be combined to create highly specific detections.

Example Rule: Multiple Failed Logins

The following example generates an alert when repeated failed logins are detected:

<rule id="100500" level="10">
  <if_sid>60122</if_sid>
  <description>Multiple failed login attempts detected</description>
</rule>

This rule builds upon an existing Wazuh rule and raises the severity of repeated authentication failures.

You can further enhance detection logic using frequency and timeframe conditions.

Deploying Custom Rules

Editing local_rules.xml

Custom rules should be added to:

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

This file is preserved during upgrades and serves as the recommended location for organization-specific rules.

Reloading Configuration

After adding new rules:

systemctl restart wazuh-manager

Restarting the manager loads the updated rule set.

Always validate XML syntax before restarting to avoid configuration errors.

Testing Custom Alerts

Simulating Failed Logins

After deploying a rule, generate test events.

For example:

• Attempt multiple failed logins
• Trigger account lockouts
• Execute monitored PowerShell commands

Controlled testing confirms that detection logic behaves as expected.

Verifying Detections

Verify successful alert generation by:

1. Opening the Wazuh Dashboard.
2. Searching for the custom rule ID.
3. Reviewing generated alerts.
4. Confirming severity levels.

For detailed testing procedures, see How to Test Wazuh Rules.

Integrating Sysmon with Wazuh

Windows Event Logs provide valuable visibility, but many organizations deploy Sysmon to capture additional telemetry that is not available through native Windows logging.

Sysmon significantly improves endpoint visibility and strengthens threat detection capabilities.

Why Sysmon Improves Visibility

Detailed Endpoint Telemetry

Sysmon extends Windows logging by recording:

• Process execution
• Network connections
• Registry modifications
• Driver loading
• File creation activity
• Named pipe activity

These events provide significantly more context than standard Windows Event Logs.

Advanced Threat Detection

Sysmon helps identify:

• Malware execution
• Command-and-control communications
• Credential dumping activity
• Persistence mechanisms
• Lateral movement behavior

According to Microsoft Sysinternals, Sysmon provides detailed monitoring capabilities specifically designed to support incident detection and forensic investigations.

Installing Sysmon

Deployment Methods

Sysmon can be deployed using:

• Manual installation
• Group Policy
• Microsoft Intune
• SCCM
• PowerShell automation

Most enterprises automate deployment across all Windows endpoints.

Recommended Configurations

Sysmon is highly configurable through XML configuration files.

Popular community-maintained configurations include:

• SwiftOnSecurity Sysmon Config
• Olaf Hartong Sysmon Modular

These configurations provide broad detection coverage while minimizing unnecessary logging.

Configuring Wazuh to Collect Sysmon Events

Event Channel Setup

Sysmon events are stored in:

Microsoft-Windows-Sysmon/Operational

To collect Sysmon events, add the following configuration to the Wazuh Agent:

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Restart the agent after updating the configuration.

Validation Steps

Verify successful integration by:

1. Opening Event Viewer.
2. Confirming Sysmon events exist.
3. Checking Wazuh alerts.
4. Searching for Sysmon Event IDs in the Dashboard.

You should begin seeing Sysmon telemetry shortly after configuration is applied.

High-Value Sysmon Events to Monitor

Process Creation

Event ID 1

Tracks:

• Executable launches
• Command-line arguments
• Parent-child process relationships

One of the most valuable data sources for threat hunting.

Network Connections

Event ID 3

Captures:

• Outbound connections
• Remote IP addresses
• Connection ports
• Protocol details

Useful for identifying command-and-control activity.

Registry Modifications

Event IDs 12, 13, 14

Detect:

• Persistence modifications
• Registry autoruns
• Suspicious registry changes

Driver Loading

Event ID 6

Records:

• Driver installation
• Kernel-level activity
• Potential rootkit behavior

File Creation Events

Event ID 11

Captures:

• Malware staging
• File drops
• Suspicious file creation

Many ransomware investigations rely heavily on Sysmon file creation telemetry.

For ransomware-focused monitoring, see How to Detect Ransomware Activity Using Wazuh.

Building Detection Use Cases

Collecting Windows Event Logs is only the first step.

The real value comes from using those logs to detect threats and suspicious behavior.

Detecting Brute Force Attacks

Brute force attacks remain one of the most common attack techniques against Windows systems.

Failed Login Thresholds

Monitor repeated occurrences of:

• Event ID 4625
• Authentication failures from the same IP
• Multiple failures targeting the same account

Typical thresholds include:

• 5 failures in 5 minutes
• 10 failures in 15 minutes
• Account-specific thresholds

Wazuh rules can automatically generate alerts when thresholds are exceeded.

Account Lockout Monitoring

Event ID 4740 indicates account lockouts.

Monitoring lockouts helps identify:

• Password spraying attacks
• Brute-force attempts
• Misconfigured services

Detecting Privileged Account Abuse

Administrative accounts represent high-value targets.

Administrative Activity Monitoring

Monitor:

• Event ID 4672
• Group membership changes
• Administrator logins
• Privileged account creation

Unexpected privileged activity often warrants investigation.

Detecting PowerShell Abuse

PowerShell is frequently leveraged by attackers after initial compromise.

Encoded Commands

Attackers often use:

powershell.exe -EncodedCommand

Monitoring encoded command execution helps identify suspicious activity.

Suspicious Script Execution

Look for:

• Download cradles
• Remote script execution
• Obfuscated commands
• Credential harvesting scripts

Combining PowerShell logs with Sysmon process creation events significantly improves visibility.

Detecting Persistence Techniques

Persistence allows attackers to maintain access after a reboot.

Scheduled Tasks

Monitor:

• New task creation
• Task modifications
• Unexpected scheduled executions

Scheduled tasks are a common persistence mechanism.

Registry Autoruns

Track:

• Run keys
• RunOnce keys
• Startup-related registry changes

Sysmon registry events provide excellent visibility into these modifications.

Service Creation

Monitor Event ID 4697 and Sysmon service-related activity.

Unexpected service creation often indicates malware deployment or persistence.

Detecting Malware Activity

Defender Alerts

Windows Defender events can reveal:

• Malware detections
• Quarantined files
• Suspicious processes
• Threat remediation actions

These alerts should typically generate high-priority notifications.

Sysmon Indicators

Common Sysmon-based malware indicators include:

• Suspicious child processes
• Unusual outbound connections
• Registry persistence
• File drops in temporary directories

Combining Sysmon and Defender telemetry provides significantly stronger endpoint visibility.

Visualizing Windows Event Logs in the Wazuh Dashboard

The Wazuh Dashboard transforms raw Windows events into searchable, actionable security intelligence.

Searching Windows Events

Query Filters

The Dashboard supports powerful filtering capabilities.

Common filters include:

agent.name:"DC01"

rule.level >= 10

win.system.providerName:"Microsoft-Windows-Security-Auditing"

These filters help analysts quickly locate relevant events.

Event ID Searches

Event-specific searches are frequently used during investigations.

Examples:

win.system.eventID:4625

win.system.eventID:4672

win.system.eventID:4740

Filtering by Event ID accelerates threat hunting and incident response.

Creating Custom Dashboards

Security-Focused Visualizations

Organizations often create dashboards for:

• Failed logins
• Malware detections
• PowerShell activity
• Administrative actions
• Sysmon events

Custom visualizations help analysts identify trends and anomalies.

Authentication Monitoring Dashboards

Authentication dashboards commonly include:

• Successful logons
• Failed logons
• Account lockouts
• Privileged account activity
• Geographic login distribution

These dashboards are often among the most frequently used by security operations teams.

Building Alerts and Reports

Automated Reporting

Wazuh supports automated reporting for:

• Security incidents
• Compliance audits
• Authentication activity
• Malware detections

Reports help communicate security metrics to stakeholders and auditors.

Scheduled Reports

Organizations commonly schedule:

• Daily security summaries
• Weekly threat reports
• Monthly compliance reports
• Executive security dashboards

These reports provide ongoing visibility into Windows security events and help demonstrate compliance with frameworks such as PCI DSS, HIPAA, NIST, and ISO 27001.

For long-term storage and reporting optimization, see How to Configure Wazuh Log Retention.

Troubleshooting Windows Event Log Collection

Even with a properly configured deployment, issues can occasionally prevent Windows Event Logs from appearing in Wazuh.

Understanding the most common causes can help you quickly restore visibility and ensure critical security events are being collected.

No Windows Events Appearing

If no Windows events are showing in the Wazuh Dashboard, begin by verifying that the agent is properly configured and actively connected to the Wazuh Manager.

Agent Configuration Issues

One of the most common causes is an incorrect ossec.conf configuration.

Verify that:

• The desired event channels are configured correctly.
• The eventchannel log format is being used.
• XML syntax is valid.
• The Wazuh Agent has been restarted after changes.

For example:

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

Even a minor configuration error can prevent log collection.

Event Channel Permissions

The Wazuh Agent must have sufficient permissions to access the Windows Event Log channels.

Verify:

• The Wazuh service is running.
• The service account has access to Event Logs.
• Security policies have not restricted log access.

Certain hardened environments may require additional permissions for successful event collection.

Missing Security Logs

If Application and System logs are visible but Security events are missing, the issue is usually related to auditing configuration or permissions.

Audit Policy Configuration

Windows only records Security events when auditing is enabled.

Review the audit policy using:

auditpol /get /category:*

Important audit categories include:

• Logon/Logoff
• Account Management
• Policy Change
• Privilege Use
• Object Access

Microsoft recommends enabling Advanced Audit Policies to improve security visibility and event granularity.

Access Permissions

The Security log has stricter access controls than other event channels.

Verify:

• Administrative privileges are available.
• Security log access has not been restricted.
• Group Policy settings are not blocking access.

Agent Not Sending Events

In some cases, the agent collects events but fails to forward them to the Wazuh Manager.

Connectivity Problems

Check the following:

• DNS resolution
• Network routing
• Firewall rules
• Manager availability
• Agent registration status

Connectivity issues are among the most common causes of missing data.

For detailed troubleshooting, see Wazuh Agent Not Connecting to Manager? 12 Fixes That Actually Work.

Service Failures

Verify that the Wazuh Agent service is running:

Get-Service Wazuh

Expected output:

Status : Running

If the service repeatedly stops, review agent logs for configuration errors or system-level issues.

Excessive Log Volume

Large Windows environments can generate significant volumes of event data.

Without tuning, excessive logging can impact storage and analyst efficiency.

Filtering Noisy Events

Consider filtering:

• Low-value informational events
• Repetitive application logs
• Known benign activity
• Excessively verbose channels

Reducing unnecessary events helps analysts focus on meaningful security activity.

Performance Optimization

To improve performance:

• Monitor only required event channels.
• Implement log retention policies.
• Use custom rules to suppress noise.
• Archive older data appropriately.

Organizations managing large deployments should also review How to Configure Wazuh Log Retention.

Event Parsing Issues

Occasionally events may arrive but fail to trigger expected alerts.

Decoder Troubleshooting

Wazuh relies on decoders to interpret incoming events.

Verify:

• Events are arriving correctly.
• The appropriate decoder is being applied.
• Custom event formats are supported.

If events are not being parsed correctly, custom decoder development may be required.

Rule Validation

Detection rules should be tested whenever changes are made.

Validate:

• Rule syntax
• Rule hierarchy
• Event matching conditions
• Alert severity levels

For detailed testing procedures, see How to Create Custom Detection Rules in Wazuh.

Best Practices for Windows Event Monitoring with Wazuh

Following proven monitoring practices can significantly improve detection quality while reducing operational overhead.

Monitor High-Value Event IDs

Focus on Security-Relevant Logs

Rather than collecting every possible event, prioritize high-value security events such as:

• 4624 – Successful Logon
• 4625 – Failed Logon
• 4672 – Special Privileges Assigned
• 4720 – User Created
• 4740 – Account Lockout
• 4697 – Service Installation

These events often provide the greatest security value and support both detection and investigation efforts.

Enable Advanced Auditing

Improve Event Visibility

Windows Advanced Audit Policies provide significantly more visibility than default audit settings.

Benefits include:

• Detailed authentication events
• Object access monitoring
• Process creation auditing
• Policy change tracking
• Privilege usage visibility

Advanced auditing improves both detection coverage and forensic capabilities.

Microsoft’s security guidance recommends advanced auditing for organizations seeking stronger security monitoring and incident response capabilities.

Deploy Sysmon Across Endpoints

Gain Deeper Telemetry

Sysmon provides telemetry that is not available through standard Windows Event Logs.

Benefits include:

• Process creation visibility
• Network connection tracking
• Registry monitoring
• Driver load monitoring
• File creation events

Many security practitioners consider Sysmon one of the most valuable Windows telemetry sources available.

For deployment guidance, review the Sysmon integration section earlier in this guide.

Create Environment-Specific Rules

Reduce False Positives

Every environment generates unique activity patterns.

Custom rules help:

• Suppress known benign behavior
• Highlight high-risk actions
• Prioritize critical systems
• Improve alert quality

Organizations that tune detections generally achieve higher analyst efficiency and lower alert fatigue.

For additional guidance, see How to Reduce False Positives in Wazuh.

Review Alerts Regularly

Continuous Security Improvement

Alert reviews help identify:

• Detection gaps
• Misconfigured rules
• Emerging attack patterns
• New monitoring requirements

Regular reviews ensure that monitoring remains aligned with organizational risks.

Retain Logs Appropriately

Compliance and Forensic Requirements

Log retention should be based on:

• Regulatory requirements
• Investigation needs
• Storage capacity
• Security policies

Longer retention periods improve historical investigations but require additional storage planning.

Organizations with compliance requirements often maintain logs for months or years to support audits and forensic investigations.

For retention planning, see How to Configure Wazuh Log Retention.

Frequently Asked Questions

Question: Does Wazuh collect Windows Event Logs by default?

Yes. The Windows Wazuh Agent typically includes default monitoring for the Security, System, and Application event channels.

Additional channels such as PowerShell, Sysmon, and Windows Defender can be configured manually.

Question: Which Windows Event IDs should I monitor first?

Start with high-value security events including:

• 4624 – Successful Logon
• 4625 – Failed Logon
• 4672 – Special Privileges Assigned
• 4720 – User Created
• 4732 – Group Membership Added
• 4740 – Account Lockout

These events provide excellent visibility into authentication and privilege-related activity.

Question: Can Wazuh monitor Sysmon logs?

Yes. Wazuh can collect Sysmon events using the following event channel:

Microsoft-Windows-Sysmon/Operational

Sysmon significantly expands endpoint visibility by providing process, network, registry, and file activity telemetry.

Question: How do I monitor PowerShell activity with Wazuh?

Enable collection of the PowerShell Operational channel:

<localfile>
  <location>Microsoft-Windows-PowerShell/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

This allows Wazuh to collect PowerShell execution events and script activity.

Question: Why are Security events not appearing in Wazuh?

Common causes include:

• Disabled audit policies
• Incorrect event channel configuration
• Insufficient permissions
• Agent connectivity issues
• Service failures

Verify auditing settings and confirm that the Security channel is properly configured.

Question: Can Wazuh detect brute-force login attempts from Windows logs?

Yes. Wazuh can detect brute-force activity by monitoring repeated Event ID 4625 authentication failures and correlating them using built-in or custom detection rules.

Organizations frequently implement threshold-based alerts for failed login attempts to identify password spraying and brute-force attacks.

Question: How many Windows endpoints can Wazuh monitor?

Wazuh is designed to scale from small environments to large enterprise deployments.

The exact number depends on:

• Hardware resources
• Event volume
• Indexer capacity
• Retention requirements
• Detection workload

Large deployments often use clustered architectures to support thousands of endpoints. See How to Build a Wazuh Indexer Cluster for scalability guidance.

Conclusion

Windows Event Logs provide some of the most valuable security and operational telemetry available in Microsoft environments.

By centralizing these logs within Wazuh, organizations gain visibility into authentication activity, privilege changes, malware detections, system events, and many other critical security indicators.

Throughout this guide, we’ve covered how to monitor Windows Event Logs using Wazuh, including:

• Installing the Wazuh Agent
• Configuring Event Log collection
• Monitoring additional event channels
• Integrating Sysmon
• Building custom detections
• Visualizing events in the Wazuh Dashboard
• Troubleshooting common issues

Key Security Benefits

Centralized Visibility

Wazuh consolidates Windows Event Logs from multiple systems into a single platform, making investigations faster and more efficient.

Threat Detection

Built-in rules, custom detections, event correlation, and Sysmon integration help identify malicious activity before it becomes a major incident.

Compliance Support

Centralized log collection and retention support regulatory requirements such as:

• PCI DSS
• HIPAA
• NIST
• ISO 27001

Next Steps

To further enhance your Windows monitoring capabilities:

1. Deploy Sysmon across all Windows endpoints.
2. Build custom detection rules tailored to your environment.
3. Tune alerts to reduce false positives.
4. Expand monitoring coverage to additional event channels.
5. Integrate Windows telemetry with other log sources such as firewalls, cloud platforms, and threat intelligence feeds.

You may also find these guides helpful:

• How to Create Custom Detection Rules in Wazuh
• How to Test Wazuh Rules
• How to Detect Ransomware Activity Using Wazuh
• How to Collect Firewall Logs in Wazuh
• How to Integrate Wazuh with VirusTotal for Threat Intelligence

With the right event channels, detection rules, and monitoring practices in place, Wazuh can serve as a powerful platform for Windows security monitoring, threat detection, and compliance management.