Security teams rely on visibility into user activity, authentication events, privilege changes, file access, and system configuration changes to identify malicious behavior before it escalates into a breach. This is where Wazuh audit logs become essential.

By collecting and analyzing audit data from operating systems, applications, cloud platforms, and identity services, Wazuh enables organizations to detect suspicious activity, investigate incidents, and meet regulatory compliance requirements from a centralized platform.

Unlike basic log collection, audit logging focuses on recording security-relevant events that provide accountability and traceability.

Whether you’re monitoring failed login attempts, privilege escalation, file modifications, or administrative actions, properly configured audit logs provide the evidence needed for both real-time threat detection and forensic investigations.

Configuring audit logs in Wazuh offers several important benefits:

Detect unauthorized access and privilege escalation attempts
Improve threat hunting with detailed user activity records
Support compliance frameworks such as PCI DSS, HIPAA, ISO 27001, NIST, and CIS Controls
Accelerate incident response through centralized security monitoring
Correlate audit events across endpoints, servers, and cloud environments

By the end of this guide, you’ll understand how Wazuh collects audit events, which audit sources are supported, how audit logging differs from traditional system logging, and how to configure and optimize audit logging for comprehensive security monitoring across your environment.

What Are Wazuh Audit Logs?

Audit logs are detailed records of security-related activities performed by users, applications, services, and operating systems.

Unlike general system logs, which primarily record operational information and software events, audit logs are specifically designed to answer questions such as:

Who performed an action?
What action was performed?
When did it happen?
Where did it occur?
Was the action successful or denied?

These records are critical during security investigations because they establish a chronological trail of system activity.

Within Wazuh, audit logs are collected by the Wazuh agent from multiple operating system components and security tools.

The agent forwards the events to the Wazuh manager, where decoders normalize the log data and detection rules evaluate each event against known attack techniques, suspicious behaviors, and compliance requirements.

Matching events generate alerts that are indexed and displayed in the Wazuh Dashboard for analysis.

Wazuh supports audit log collection from numerous operating systems and platforms, including:

Linux servers
Windows workstations and servers
macOS endpoints
Cloud platforms
Network devices
Identity providers
Security applications

Common audit data sources include Linux’s Audit Framework (auditd), Windows Security Event Logs, Sysmon, Active Directory auditing, authentication logs, cloud audit services, and many third-party security products.

One important distinction is the difference between audit logs and standard system logs.

Standard system logs typically capture application messages, service startup information, hardware events, and operational status updates.

While useful for troubleshooting, they often lack the detailed security context needed for investigations.

Audit logs, on the other hand, record security-sensitive activities such as:

User authentication
Permission changes
Administrative actions
File access
Policy modifications
Process execution
Security configuration changes

Because of their forensic value, audit logs form the foundation of many detection rules and compliance reporting requirements.

For organizations implementing a Security Information and Event Management (SIEM) platform, properly configured audit logs provide the high-quality telemetry necessary to detect insider threats, compromised accounts, privilege abuse, ransomware activity, and lateral movement.

Common Audit Log Sources Supported by Wazuh

Wazuh can ingest audit events from numerous operating systems and security platforms, allowing organizations to centralize security monitoring across hybrid environments.

Each log source provides different visibility into user behavior, system activity, and potential attack techniques.

Linux Audit Framework (auditd)

The Linux Audit Framework (auditd) is one of the most important audit sources for Linux servers.

It records detailed security events including:

User logins and logouts
File access
File deletions
Permission changes
Process execution
Privilege escalation
System call activity
SELinux events

When integrated with Wazuh, these events are correlated with detection rules that identify suspicious administrative activity, unauthorized file access, persistence techniques, and privilege abuse.

Auditd is especially valuable for organizations that must comply with PCI DSS, HIPAA, CIS Benchmarks, or government security standards.

Related Guide: How to Add Linux Endpoints to Wazuh

Windows Security Event Logs

Windows Security Event Logs contain authentication, authorization, and account management events generated by Windows systems.

Common events include:

Successful logins
Failed login attempts
Account lockouts
User creation
Group membership changes
Password resets
Privilege assignments
Security policy modifications

Wazuh continuously monitors these logs and generates alerts when suspicious patterns emerge, such as repeated authentication failures or unauthorized administrative changes.

Organizations often combine these logs with custom detection rules to improve visibility into Windows attack techniques.

Sysmon Events

Microsoft Sysmon extends Windows logging by providing detailed endpoint telemetry that is not available through native Windows Event Logs.

Sysmon records events such as:

Process creation
Command-line execution
Network connections
Driver loading
DLL loading
Registry modifications
File creation timestamps
Process injection activity

These events greatly improve detection coverage for advanced threats including ransomware, malware execution, living-off-the-land attacks, and credential theft.

Many security researchers recommend Sysmon because it significantly increases endpoint visibility while integrating well with SIEM platforms like Wazuh.

Active Directory Audit Logs

Active Directory auditing provides visibility into identity-related events occurring across Windows domains.

Common monitored activities include:

User account creation
Group policy changes
Domain administrator activity
Password modifications
Organizational Unit changes
Security group membership updates
Privileged account usage

Since identity systems are a frequent target of attackers, monitoring Active Directory audit logs enables Wazuh to detect privilege escalation, persistence, and lateral movement techniques much earlier in the attack lifecycle.

Authentication Logs

Authentication logs record login activity across Linux, Windows, network devices, VPNs, cloud services, and applications.

These logs commonly include:

Successful authentication
Failed authentication
Multi-factor authentication events
SSH logins
RDP logins
VPN access
Remote administration sessions

By correlating authentication events from multiple sources, Wazuh can detect brute-force attacks, password spraying, credential stuffing, impossible travel scenarios, and compromised user accounts.

File Integrity Monitoring (FIM) Events

Although File Integrity Monitoring is separate from operating system auditing, FIM events are an important audit source because they record changes made to monitored files and directories.

Wazuh tracks events such as:

File creation
File deletion
File modification
Permission changes
Ownership changes
Hash changes

These records help security teams identify ransomware encryption activity, unauthorized software installation, web shell deployment, and unexpected configuration changes.

Organizations frequently correlate FIM events with user authentication logs to determine who modified a sensitive file and when the change occurred.

Cloud Audit Logs (AWS CloudTrail, Azure Activity Logs, Google Cloud Audit Logs)

Modern organizations increasingly rely on cloud audit logs to monitor administrative activity across cloud infrastructure.

Wazuh supports ingesting audit data from major cloud providers, including:

AWS CloudTrail — Records API calls, IAM changes, resource creation, and administrative actions.
Azure Activity Logs — Tracks Azure resource operations, policy changes, deployments, and management events.
Google Cloud Audit Logs — Records administrative actions, data access, and policy modifications across Google Cloud services.

Centralizing these cloud audit logs alongside endpoint telemetry enables analysts to correlate user activity across on-premises and cloud environments, providing a unified view of security events.

The importance of centralized logging is emphasized by both the National Institute of Standards and Technology (NIST) and the Center for Internet Security (CIS), which recommend collecting audit logs from all critical systems to improve detection capabilities and support incident investigations.

Prerequisites

Before configuring Wazuh audit logs, verify that your environment meets several foundational requirements.

Proper preparation helps ensure reliable event collection, accurate alerting, and efficient troubleshooting throughout the deployment.

Wazuh Manager Installation

A functioning Wazuh manager is required to receive, process, and analyze audit events collected from endpoints.

The manager performs several key tasks:

Receives events from Wazuh agents
Decodes raw log data into structured fields
Matches events against detection rules
Generates alerts
Forwards alerts to the Wazuh Indexer for storage

If you’re deploying Wazuh for the first time, ensure your manager is running the latest supported version to take advantage of newer decoders, rules, and performance improvements.

Wazuh Agent Deployment

Each endpoint that generates audit events should have the Wazuh agent installed and properly registered with the manager.

The agent is responsible for collecting local audit logs and securely forwarding them for analysis.

Supported endpoints include:

Linux servers
Windows desktops and servers
macOS systems
Cloud virtual machines
Container hosts

Verify that agents are online before enabling audit log monitoring.

An offline or misconfigured agent will prevent audit events from reaching the manager.

Administrative Privileges

Configuring audit logging typically requires elevated privileges because you’ll be modifying operating system security settings and installing or configuring system services.

Depending on the operating system, you may need:

Root or sudo access on Linux
Administrator privileges on Windows
Permission to modify audit policies
Access to Wazuh configuration files

Without sufficient privileges, audit rules may fail to load or essential logs may not be accessible.

Time Synchronization (NTP)

Accurate timestamps are essential for event correlation across multiple systems.

If servers have inconsistent clocks, security investigations become significantly more difficult because:

Event timelines become inaccurate.
Correlation rules may fail.
Distributed attacks become harder to reconstruct.
Compliance reports may contain inconsistent timestamps.

Synchronize all Wazuh components, including managers, agents, indexers, and monitored systems, using Network Time Protocol (NTP) or another trusted time source.

Required Ports and Network Connectivity

Agents must be able to communicate reliably with the Wazuh manager.

Before enabling audit logging, verify that:

Firewalls permit required Wazuh communication ports.
Network routes are available between agents and managers.
TLS communication is functioning correctly.
DNS resolution is working where applicable.
No security appliance is blocking agent traffic.

If connectivity issues exist, audit events may never reach the manager, even if audit logging is correctly configured.

Basic Understanding of Wazuh Rules and Decoders

Audit logs become useful only after Wazuh successfully interprets them.

Understanding the following components will make configuration much easier:

Decoders extract structured information from raw logs.
Rules determine whether an event should generate an alert.
Rule groups categorize related detections.
Alert levels define event severity.

Knowing how these components interact makes it easier to customize detections and troubleshoot missing alerts.

Related Guides:

Understanding the Wazuh Audit Log Architecture

Understanding how audit events flow through the Wazuh platform makes it much easier to troubleshoot collection issues, optimize performance, and customize detection rules.

Every audit event passes through several processing stages before it appears in the Wazuh Dashboard.

Audit Event Generation

Everything begins on the monitored endpoint.

Operating systems and applications continuously generate audit events whenever security-relevant actions occur, such as:

User authentication
File access
Permission changes
Process execution
Administrative actions
Policy modifications
Network access
Service creation

For Linux systems, these events are commonly produced by the Linux Audit Framework (auditd), while Windows relies on Security Event Logs, Sysmon, and Active Directory auditing.

Log Collection by the Wazuh Agent

The Wazuh agent continuously monitors configured log sources for new audit events.

Depending on the operating system, the agent may collect events from:

Audit log files
Windows Event Channels
Sysmon logs
Authentication logs
Journal logs
File Integrity Monitoring events
Cloud service integrations

The agent securely forwards collected events to the Wazuh manager using encrypted communication, minimizing the risk of interception or tampering during transmission.

Event Decoding

Once the manager receives an event, it passes through the decoding engine.

Decoders identify:

Log format
Event type
Timestamp
Username
Source IP address
Destination
Process name
Command executed
Event identifiers
Additional metadata

This process transforms unstructured log data into normalized fields that detection rules can evaluate consistently across different operating systems and log sources.

Related Guide: Wazuh Decoder Guide

Rule Matching

After decoding, Wazuh evaluates the event against its ruleset.

Rules determine whether the event represents:

Normal activity
Policy violations
Suspicious behavior
Known attack techniques
Compliance findings
Threat indicators

Rules can also correlate multiple audit events together, allowing Wazuh to identify attack patterns that would otherwise appear harmless when viewed individually.

Organizations frequently customize these rules to match their own security policies and reduce unnecessary alerts.

Alert Generation

If a rule matches the decoded event, Wazuh generates an alert containing information such as:

Rule ID
Alert level
Timestamp
Agent name
Event source
User involved
MITRE ATT&CK mappings (when applicable)
Compliance mappings
Full event details

Higher-severity alerts can also trigger automated responses, email notifications, or integrations with third-party incident response platforms.

Related Guide: How to Configure Wazuh Alerts

Indexing in the Wazuh Indexer

Generated alerts are forwarded to the Wazuh Indexer, where they are indexed for fast searching and long-term storage.

The indexer enables analysts to:

Search millions of audit events quickly
Aggregate security data
Build dashboards
Perform forensic investigations
Execute threat hunting queries

Efficient indexing is especially important in large environments where thousands of audit events may be generated every second.

Related Guide: The Ultimate Wazuh Indexer Guide

Visualization in the Wazuh Dashboard

Finally, indexed audit data becomes available in the Wazuh Dashboard.

Security analysts can:

Search audit events
Filter by user, host, or event type
Build visualizations
Investigate alerts
Review compliance reports
Create saved searches
Monitor dashboards in real time

This centralized visibility allows security teams to quickly detect abnormal activity across endpoints, servers, and cloud infrastructure.

How to Configure Audit Logs on Linux

Linux systems provide one of the richest sources of security telemetry through the Linux Audit Framework (auditd).

Integrating auditd with Wazuh enables detailed monitoring of authentication events, privilege escalation, file access, command execution, and administrative actions.

Install and Enable auditd

Most enterprise Linux distributions include the Linux Audit Framework in their repositories.

On Debian and Ubuntu:

sudo apt update
sudo apt install auditd audispd-plugins

On RHEL, Rocky Linux, AlmaLinux, and CentOS:

sudo dnf install audit

sudo yum install audit

Enable and start the service:

sudo systemctl enable auditd
sudo systemctl start auditd

Verify that the service is running:

sudo systemctl status auditd

Configure Audit Rules

Audit rules define which activities the Linux kernel records.

Rules can monitor:

Sensitive files
Directory access
Command execution
System calls
Privilege escalation
User account modifications
Security configuration changes

For example, to monitor changes to the /etc/passwd file:

-w /etc/passwd -p wa -k identity

To monitor /etc/shadow:

-w /etc/shadow -p wa -k identity

Many organizations maintain audit rules in files under:

/etc/audit/rules.d/

Keeping rules modular makes them easier to maintain and audit over time.

Verify Audit Rule Loading

After updating your rules, reload them and verify they are active.

Load the rules:

sudo augenrules --load

Display active rules:

sudo auditctl -l

You should confirm that newly added rules appear in the output before proceeding.

If expected rules are missing, review the syntax and audit daemon logs for errors.

Configure the Wazuh Agent to Monitor Audit Logs

Next, configure the Wazuh agent to collect audit events.

On many Linux distributions, audit logs are stored at:

/var/log/audit/audit.log

Add or verify the corresponding <localfile> configuration in the agent’s ossec.conf:

<localfile>
  <location>/var/log/audit/audit.log</location>
  <log_format>audit</log_format>
</localfile>

This instructs the Wazuh agent to continuously monitor the Linux Audit Framework output and forward new events to the manager.

Restart Required Services

After updating both auditd and the Wazuh agent configuration, restart the necessary services.

Restart auditd:

sudo systemctl restart auditd

Restart the Wazuh agent:

sudo systemctl restart wazuh-agent

Confirm both services are running without errors before generating test events.

Validate Event Collection

Finally, verify that audit events are successfully reaching the Wazuh manager.

A simple validation process includes:

Generate an audited event, such as modifying a monitored file.
Confirm the event appears in the local audit log (/var/log/audit/audit.log).
Verify the Wazuh agent forwards the event.
Search for the event in the Wazuh Dashboard.
Confirm that the appropriate rule triggered and an alert was generated.

If events do not appear, check:

auditd service status
Loaded audit rules
Wazuh agent logs
Agent-to-manager connectivity
Decoder and rule matching

Related Guides:

How to Configure Audit Logs on Windows

Windows environments generate a wealth of security telemetry that can help detect unauthorized access, privilege escalation, credential theft, and lateral movement.

By enabling Advanced Audit Policies, collecting Windows Security Event Logs, and optionally deploying Sysmon, you can significantly improve Wazuh’s detection capabilities.

Enable Advanced Audit Policy

Windows Advanced Audit Policy provides granular control over which security events are recorded.

Unlike the basic audit policy settings, Advanced Audit Policy allows administrators to selectively enable auditing for specific categories.

Some of the most valuable audit categories include:

Account Logon
Logon/Logoff
Account Management
Object Access
Policy Change
Privilege Use
Process Creation
Detailed Tracking
System Events
DS Access (for Domain Controllers)

You can configure these settings through:

Local Group Policy (gpedit.msc)
Group Policy Management Console (GPMC)
PowerShell
Active Directory Group Policy Objects

For enterprise deployments, configuring audit policies through Group Policy ensures consistency across all Windows endpoints.

Configure Windows Security Auditing

After enabling Advanced Audit Policy, configure the specific audit categories that align with your security and compliance requirements.

Common events worth collecting include:

Audit Category	Typical Events
Logon Events	Successful and failed logins
Account Management	User creation, deletion, password changes
Privilege Use	Administrative privilege assignments
Policy Changes	Security policy modifications
Object Access	Access to sensitive files and folders
Process Tracking	Process creation and termination
System Events	Service starts, shutdowns, system integrity events

Organizations often begin with Microsoft’s recommended security baselines and then expand auditing based on their operational needs to avoid generating unnecessary event volume.

Install Sysmon (Optional but Recommended)

Although Windows Security Event Logs provide valuable audit data, Sysmon (System Monitor) offers much deeper visibility into endpoint activity.

Sysmon can record events such as:

Process creation with command-line arguments
Network connections
Registry modifications
Driver loading
DLL loading
File creation timestamps
WMI activity
Process injection
Named pipe creation

This additional telemetry greatly improves detection coverage for advanced threats, including ransomware, malware, and living-off-the-land attacks.

Most security teams deploy Sysmon using a community-maintained configuration such as the SwiftOnSecurity Sysmon Config or the Olaf Hartong Sysmon Modular Configuration, which filter noisy events while capturing high-value security telemetry.

Configure Wazuh Agent Log Collection

Once Windows auditing is enabled, configure the Wazuh agent to monitor the appropriate Windows Event Channels.

A typical configuration in ossec.conf includes:

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

You can also monitor additional channels such as:

Microsoft-Windows-Sysmon/Operational
Application
System
Windows PowerShell
Microsoft Defender
Windows Firewall

Collecting multiple event channels enables Wazuh to correlate authentication events, process execution, malware detections, and system changes into higher-confidence alerts.

Validate Windows Audit Events

After configuring auditing and restarting the Wazuh agent, verify that events are being collected correctly.

A simple validation process includes:

Log in to the Windows system.
Perform an action that should generate an audit event (for example, create a local user or modify a monitored file).
Open Event Viewer and confirm the event appears in the appropriate log.
Verify the Wazuh agent forwards the event to the manager.
Search for the event in the Wazuh Dashboard.
Confirm that the expected detection rule generated an alert.

If expected events are missing, verify:

Audit policies are enabled.
Event channels are configured correctly.
The Wazuh agent service is running.
Agent-to-manager communication is functioning.
The appropriate decoder and rule exist.

Related Guides:

Collecting Cloud Audit Logs

Cloud environments continuously generate audit data for administrative actions, authentication events, API calls, and resource modifications.

Centralizing these logs within Wazuh allows security teams to monitor hybrid infrastructures from a single platform and quickly detect suspicious activity across multiple cloud providers.

AWS CloudTrail Integration

AWS CloudTrail records nearly every API call made within an AWS account, making it one of the most valuable cloud audit sources.

Common events include:

IAM user activity
Role assumption
EC2 instance creation
S3 bucket modifications
Security Group changes
CloudTrail configuration updates
AWS Console logins
API calls from SDKs and CLI tools

Wazuh can ingest CloudTrail logs through supported integrations, allowing rules to detect unauthorized administrative actions, privilege escalation, or unusual API activity.

Organizations should enable CloudTrail across all AWS Regions, including newly created Regions, to avoid blind spots in monitoring.

Azure Activity Logs Integration

Azure Activity Logs provide visibility into operations performed on Azure resources and subscriptions.

Common events include:

Virtual machine creation
Resource deletion
Network Security Group modifications
RBAC role assignments
Policy updates
Subscription changes
Service Health notifications

Wazuh can collect Azure Activity Logs to detect unauthorized infrastructure changes and administrative actions that could indicate account compromise or insider threats.

Administrators should also consider collecting Microsoft Entra ID (formerly Azure AD) audit and sign-in logs for more comprehensive identity monitoring.

Google Cloud Audit Logs Integration

Google Cloud Audit Logs record administrative, data access, and system events across Google Cloud services.

Key event categories include:

Admin Activity logs
Data Access logs
Policy Denied logs
System Event logs

Typical monitored actions include:

IAM policy changes
Compute Engine instance management
Cloud Storage access
Kubernetes administration
Service account usage
API enablement

By ingesting these logs into Wazuh, security teams gain visibility into configuration changes, unauthorized API usage, and suspicious administrative activity across Google Cloud environments.

Best Practices for Centralized Cloud Auditing

Collecting cloud audit logs is only the first step.

To maximize their value, organizations should implement a consistent logging strategy across all cloud environments.

Recommended best practices include:

Enable auditing in every cloud account and subscription.
Collect logs from all supported regions.
Synchronize timestamps across cloud and on-premises systems.
Retain logs according to compliance requirements.
Correlate cloud audit logs with endpoint and identity events.
Protect audit logs from unauthorized modification or deletion.
Regularly review detection rules for new cloud attack techniques.

The Cybersecurity and Infrastructure Security Agency (CISA) recommends maintaining centralized logging and continuous monitoring across cloud environments to improve detection and incident response capabilities.

Creating Custom Detection Rules for Audit Logs

Although Wazuh includes thousands of built-in detection rules, organizations often need custom rules to monitor proprietary applications, internal security policies, or environment-specific risks.

Creating custom audit log rules enables you to detect behaviors that default rules may not cover while tailoring alerts to your operational priorities.

Writing Custom Wazuh Rules

Custom rules are typically stored in the local rules file (for example, local_rules.xml) so they remain separate from the default ruleset and are preserved during upgrades.

A simple custom rule might look like:

<group name="audit_custom,">
  <rule id="100500" level="8">
    <if_group>auditd</if_group>
    <match>sudo</match>
    <description>Privileged command executed</description>
  </rule>
</group>

This example generates an alert whenever an audit event containing the string sudo matches the specified rule group.

When creating custom rules, use descriptive rule names and comments to simplify long-term maintenance.

Matching Specific Audit Events

Effective rules should target behaviors rather than isolated log messages.

Examples include:

Multiple failed login attempts
Privileged command execution
New administrator account creation
Changes to sensitive configuration files
Disabled security services
Unexpected scheduled task creation
Execution of tools from temporary directories
Unauthorized cloud administrative actions

By matching specific audit fields such as usernames, event IDs, process names, file paths, or command-line arguments, you can build highly targeted detections with fewer false positives.

Severity Levels

Every Wazuh rule includes a severity level that indicates the importance of the detected event.

Although organizations can customize severity assignments, a common approach is:

Severity	Typical Use
0–3	Informational events
4–7	Low-risk suspicious activity
8–10	Medium-risk security events
11–13	High-risk attacks requiring investigation
14–15	Critical incidents requiring immediate response

Consistent severity assignments help analysts prioritize investigations and automate response workflows.

Rule IDs and Organization

As your custom ruleset grows, maintaining a logical structure becomes increasingly important.

Recommended practices include:

Reserve a dedicated range of custom rule IDs.
Group related rules by technology or use case.
Use meaningful group names.
Document rule purpose and expected behavior.
Track rule ownership and revision history.

A well-organized ruleset reduces maintenance effort and minimizes conflicts during upgrades.

Testing Custom Rules

Every new rule should be tested before deployment into production.

The recommended testing workflow is:

Generate representative audit events.
Run the events through wazuh-logtest.
Verify the correct decoder is used.
Confirm the expected rule triggers.
Review alert fields and severity.
Deploy the rule to production only after successful validation.

Routine testing helps prevent missed detections and ensures rule changes do not unintentionally affect existing alerts.

Related Guides:

Reducing False Positives

Custom rules should strike a balance between sensitivity and accuracy.

Excessive false positives can overwhelm analysts and obscure genuine threats.

Several techniques can help improve rule quality:

Match on multiple event attributes instead of a single keyword.
Exclude known administrative accounts or trusted service accounts where appropriate.
Use frequency and timeframe conditions to identify repeated suspicious behavior rather than isolated events.
Fine-tune rules as infrastructure and business processes evolve.
Regularly review triggered alerts to identify noisy detections and refine matching logic.

Experienced SOC teams treat detection engineering as an ongoing process, continuously tuning rules based on operational feedback and emerging attack techniques.

Related Guide: How to Reduce False Positives in Wazuh

Filtering and Tuning Audit Logs

While comprehensive audit logging is essential for security, collecting every possible event can overwhelm analysts, consume storage, and reduce the effectiveness of threat detection.

Filtering and tuning your audit logs helps ensure that Wazuh focuses on meaningful security events while minimizing unnecessary noise.

Excluding Noisy Events

Some audit events occur so frequently that they provide little security value while significantly increasing log volume.

Examples include:

Routine system service activity
Scheduled maintenance tasks
Health check processes
Automated backup jobs
Frequent access to temporary directories
Expected application-generated events

Instead of collecting every event, identify recurring low-risk activities and exclude them using:

Linux audit rules
Windows Audit Policy configuration
Sysmon filtering rules
Wazuh decoders
Wazuh rule exceptions

Carefully evaluate exclusions before implementing them to ensure they do not create monitoring blind spots.

Suppressing Repetitive Alerts

Even valuable audit events can become problematic if they generate excessive alerts.

For example:

Thousands of failed login attempts during a password spraying attack
Continuous file modifications during software installations
Repeated service restart notifications
Automated account synchronization events

Rather than creating an alert for every occurrence, Wazuh rules can use frequency-based logic to consolidate repetitive events into more meaningful detections.

This approach allows analysts to focus on significant attack patterns instead of individual events.

Monitoring Only High-Value Assets

Not every endpoint requires the same level of auditing.

Organizations often prioritize monitoring for:

Domain Controllers
Identity providers
Database servers
Payment systems
Production web servers
Kubernetes control plane nodes
Security infrastructure
Executive workstations

Applying more detailed audit logging to these high-value assets improves visibility where attacks are most likely to have serious business impact while reducing unnecessary data collection elsewhere.

Risk-based monitoring is recommended by many cybersecurity frameworks because it aligns security resources with critical business systems.

Event Correlation Strategies

Individual audit events often appear harmless in isolation. Their true significance becomes apparent when multiple related events are correlated together.

Examples include:

Individual Events	Correlated Detection
Multiple failed logins followed by a successful login	Possible brute-force compromise
New administrator account followed by privilege escalation	Potential unauthorized persistence
PowerShell execution followed by network connections	Possible malware activity
File modification followed by service restart	Potential web shell deployment
Cloud IAM changes followed by API key creation	Suspicious administrative activity

Wazuh’s rule engine can correlate related events across multiple log sources, enabling higher-confidence detections while reducing false positives.

MITRE ATT&CK mappings included with many Wazuh rules also help analysts understand how correlated events align with known adversary techniques.

Performance Optimization

Audit logging can generate millions of events in large environments.

Proper optimization ensures Wazuh continues to perform efficiently as event volume increases.

Consider the following recommendations:

Audit only security-relevant events.
Remove obsolete audit rules.
Tune noisy detection rules.
Archive older audit data according to retention policies.
Monitor index storage utilization.
Optimize OpenSearch shard allocation.
Scale Wazuh components as log volume grows.
Regularly review ingestion performance.

Monitoring system resource usage helps identify bottlenecks before they affect detection performance.

Related Guides:

Monitoring Audit Logs in the Wazuh Dashboard

Once audit logs are collected and processed, the Wazuh Dashboard becomes the primary interface for monitoring security events, investigating incidents, and generating compliance reports.

The dashboard allows analysts to search, filter, correlate, and visualize audit data from across the entire environment.

Viewing Audit Alerts

Audit alerts appear within the Wazuh Dashboard as they are generated by detection rules.

Each alert typically includes:

Timestamp
Agent name
Hostname
Username
Source IP address
Rule ID
Alert severity
Event description
Compliance mappings
MITRE ATT&CK techniques (when applicable)

Analysts can quickly identify suspicious activities such as privilege escalation, failed authentication attempts, configuration changes, and unauthorized file access.

Searching Audit Events

Powerful search capabilities allow analysts to locate specific events during investigations.

Common searches include:

Username
Hostname
Process name
Event ID
File path
IP address
Rule ID
Alert level
Time range

Combining multiple filters helps reduce investigation time and isolate relevant events during incident response.

For example, analysts may search for all failed administrator logins originating from a specific IP address during the previous 24 hours.

Creating Dashboards

Custom dashboards allow security teams to monitor the metrics most relevant to their environment.

Typical audit dashboards include:

Authentication activity
Privileged account usage
Administrative changes
File Integrity Monitoring events
Cloud administrative actions
Endpoint security events
Failed login attempts
Compliance summaries

Well-designed dashboards provide SOC analysts with immediate visibility into emerging threats without requiring manual searches.

Building Visualizations

Visualizations help transform large volumes of audit data into actionable insights.

Common visualization types include:

Line charts showing alert trends over time
Bar charts highlighting the most active hosts
Pie charts showing event distribution by severity
Geographic maps of authentication attempts
Heat maps of login activity
Tables of top triggered rules

These visualizations make it easier to identify unusual activity, recurring attack patterns, and long-term trends.

Saved Searches

Frequently used queries can be saved for future investigations.

Examples include:

Failed administrator logins
New local administrator accounts
PowerShell execution events
Sensitive file modifications
Cloud IAM policy changes
Privilege escalation attempts

Saved searches improve analyst efficiency by eliminating the need to recreate complex search filters during every investigation.

Alert Trends

Monitoring long-term trends helps identify changes in the organization’s threat landscape.

Useful metrics include:

Daily audit event volume
Authentication failures
Malware detections
Administrative changes
Privilege escalation alerts
File Integrity Monitoring activity
Cloud administrative events
High-severity alerts

Sudden increases in any of these categories may indicate active attacks or configuration issues requiring investigation.

Compliance Reporting

Many organizations use audit logs to demonstrate compliance with regulatory requirements.

The Wazuh Dashboard can assist with reporting by providing evidence of:

User authentication
Administrative activity
Policy changes
File monitoring
Security configuration modifications
Audit trail retention
Continuous monitoring

These reports simplify security audits and help demonstrate that critical systems are being continuously monitored.

Related Guides:

Security and Compliance Benefits

Properly configured audit logging is a cornerstone of nearly every major cybersecurity and regulatory framework.

By collecting, retaining, and analyzing security-relevant events, Wazuh helps organizations strengthen their security posture while supporting audit and compliance requirements.

PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) requires organizations that process, store, or transmit payment card data to maintain comprehensive audit trails.

Wazuh supports PCI DSS objectives by helping organizations:

Record user access to cardholder data.
Monitor privileged account activity.
Detect unauthorized configuration changes.
Retain audit logs for forensic analysis.
Generate alerts for suspicious security events.

Continuous audit logging simplifies evidence collection during PCI assessments.

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) requires healthcare organizations to protect electronic protected health information (ePHI) through appropriate administrative, technical, and physical safeguards.

Audit logging supports HIPAA compliance by providing:

User access records
Authentication monitoring
Administrative activity tracking
Security incident detection
Audit trail retention
Investigation support

Comprehensive audit logs help demonstrate accountability for access to sensitive healthcare systems.

ISO 27001

ISO/IEC 27001 emphasizes logging, monitoring, and continual improvement as key components of an effective Information Security Management System (ISMS).

Wazuh contributes by enabling organizations to:

Collect centralized audit logs.
Monitor privileged activities.
Detect anomalous behavior.
Investigate security incidents.
Maintain evidence for internal and external audits.

These capabilities support multiple controls related to logging, monitoring, access management, and incident response.

NIST Cybersecurity Framework

The NIST Cybersecurity Framework (CSF) highlights continuous monitoring and event logging across its core functions, particularly Detect and Respond.

Wazuh audit logging helps organizations:

Detect malicious activity.
Monitor user behavior.
Correlate events from multiple systems.
Improve incident investigations.
Enhance visibility across hybrid environments.

Using audit logs alongside endpoint, network, and cloud telemetry enables more effective detection engineering and threat hunting.

SOC 2

Organizations seeking SOC 2 compliance must demonstrate effective security controls around system monitoring, access management, and incident detection.

Wazuh audit logs provide evidence for:

User authentication
Administrative actions
Access to critical systems
Security event monitoring
Continuous log collection
Incident investigations

Maintaining centralized, tamper-resistant audit records can significantly simplify SOC 2 assessments.

CIS Controls

The Center for Internet Security (CIS) Controls recommend centralized logging and continuous monitoring as foundational cybersecurity practices.

Wazuh helps organizations implement these recommendations by:

Collecting audit logs from endpoints, servers, and cloud services.
Monitoring authentication and privilege changes.
Detecting unauthorized administrative activity.
Correlating events across multiple log sources.
Supporting ongoing security operations and threat hunting.

Combining comprehensive audit logging with well-tuned detection rules enables organizations to improve visibility, reduce response times, and build a more resilient security monitoring program.

Related Guides:

Best Practices

A well-designed audit logging strategy requires more than simply collecting events.

Organizations must balance visibility, performance, storage requirements, and operational efficiency.

Following audit logging best practices ensures that Wazuh captures valuable security data without overwhelming analysts or infrastructure resources.

Enable Only Necessary Auditing

Collecting every possible audit event can create excessive noise and increase storage consumption without improving security visibility.

Organizations should focus auditing on security-relevant activities such as:

User authentication
Privileged account usage
File and configuration changes
Process execution
Security policy modifications
Cloud administrative actions
Access to sensitive resources

A risk-based auditing approach ensures that high-value security events receive priority while unnecessary operational noise is minimized.

For example:

Domain Controllers should receive detailed identity auditing.
Database servers should monitor access and configuration changes.
Web servers should focus on application files and administrative actions.
Developer workstations may require different audit policies than production systems.

Keep Audit Rules Organized

As environments grow, audit rules can become difficult to manage.

Poorly organized rules increase the risk of duplicate monitoring, conflicting configurations, and accidental gaps in visibility.

Recommended practices include:

Group rules by operating system or technology.
Use descriptive names and comments.
Separate production and testing rules.
Maintain version-controlled configurations.
Document the purpose of each custom rule.

For Linux systems, organize audit rules into separate files within:

/etc/audit/rules.d/

For Wazuh detection rules, maintain custom rules separately from the default ruleset to prevent upgrade conflicts.

Regularly Review Audit Policies

Audit requirements change as infrastructure, applications, and threats evolve.

Regular reviews should verify:

Required events are still being collected.
Detection rules remain relevant.
New systems are included in monitoring.
Excessive noise has been removed.
Compliance requirements are still satisfied.

Security teams should review audit configurations after:

New application deployments
Infrastructure migrations
Cloud adoption
Security incidents
Compliance assessments

Regular reviews prevent outdated audit policies from creating security blind spots.

Protect Audit Log Integrity

Audit logs are valuable evidence during security investigations, making their protection critical.

Recommended protections include:

Restrict access to audit logs.
Prevent unauthorized modification or deletion.
Use secure log forwarding.
Monitor attempts to disable logging.
Store historical logs in protected locations.
Implement appropriate retention controls.

Attackers commonly attempt to disable security monitoring after gaining access, making audit log protection an important defense mechanism.

Secure Communication Between Agents and Manager

Wazuh agents transmit audit events to the Wazuh manager using encrypted communication.

To maintain secure communication:

Use agent authentication keys.
Protect agent registration processes.
Monitor certificate expiration.
Restrict unnecessary network access.
Regularly review connected agents.

Secure agent communication prevents attackers from intercepting or manipulating security telemetry.

Related Guide: How to Fix Wazuh Certificate Errors

Monitor Storage Utilization

Audit logging can consume significant storage, especially in environments with many endpoints or detailed monitoring policies.

Monitor:

Wazuh Indexer disk usage
Alert index growth
Log retention periods
Shard allocation
Archive storage capacity

Storage monitoring prevents problems such as:

Failed indexing
Cluster health degradation
Loss of historical security data
Performance issues

Related Guide: How to Manage Wazuh Storage

Archive Historical Audit Logs

Organizations often need historical audit data for:

Security investigations
Compliance audits
Threat hunting
Legal requirements
Incident response

A good retention strategy separates frequently accessed data from long-term archives.

For example:

Recent alerts remain searchable in the Wazuh Indexer.
Older audit logs are compressed and stored in archival systems.
Retention periods align with regulatory requirements.

The correct retention period depends on business requirements, regulatory obligations, and available storage resources.

Related Guide: Wazuh Data Retention Guide

Test Alerting After Configuration Changes

Changes to audit policies, decoders, or detection rules can unintentionally break monitoring.

After making changes:

Generate test security events.
Confirm logs are collected.
Verify decoding works correctly.
Confirm rules trigger expected alerts.
Check dashboard visibility.
Validate integrations such as email or incident response platforms.

Regular testing ensures that security controls continue working as expected.

Related Guide: How to Test Wazuh Rules

Keep Wazuh and Agents Updated

Keeping Wazuh components updated ensures access to:

New detection rules
Updated decoders
Security fixes
Performance improvements
New integrations

Organizations should maintain a structured upgrade process that includes:

Testing updates in a staging environment.
Reviewing release notes.
Backing up configurations.
Validating agent compatibility.

Related Guide: How to Upgrade a Wazuh Agent

Common Wazuh Audit Log Issues

Even with proper configuration, organizations may encounter issues where audit events are missing, alerts fail to trigger, or performance decreases.

Understanding common problems helps security teams troubleshoot audit logging deployments quickly.

No Audit Events Appearing

One of the most common problems is that audit events are generated on endpoints but never appear in Wazuh.

Common causes include:

Incorrect log source configuration.
Wazuh agent service stopped.
Incorrect file paths.
Missing permissions.
Network connectivity problems.
Incorrect log format configuration.

Troubleshooting steps:

Verify the audit source is generating logs.
Check Wazuh agent status.
Review agent logs.
Confirm the configured log location.
Test the event pipeline using wazuh-logtest.

auditd Service Not Running

On Linux systems, audit collection depends heavily on the Audit Framework.

Check the service status:

sudo systemctl status auditd

Common causes of failure include:

Invalid audit rules.
Incorrect configuration files.
Permission issues.
Package installation problems.

Verify loaded rules:

sudo auditctl -l

Restart the service after correcting configuration issues.

Windows Security Events Missing

Missing Windows audit events usually occur because auditing has not been enabled correctly.

Common causes:

Advanced Audit Policy not configured.
Group Policy changes not applied.
Incorrect Event Channel configuration.
Wazuh agent permissions issues.

Verify:

Security auditing settings.
Event Viewer logs.
Wazuh agent configuration.
Domain Group Policy inheritance.

Sysmon Logs Not Collected

If Sysmon events are missing, verify:

Sysmon is installed.
The Sysmon service is running.
The correct event channel is configured.
The Wazuh agent monitors the Sysmon channel.

Example:

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

Cloud Audit Logs Not Arriving

Cloud integrations can fail because of:

Incorrect credentials.
Missing permissions.
Invalid API configuration.
Incorrect cloud region settings.
Expired authentication tokens.

Troubleshooting should include:

Reviewing cloud integration configuration.
Testing API access.
Checking Wazuh module logs.
Verifying required permissions.

Rules Not Triggering

Events may appear in Wazuh but fail to generate alerts.

Common causes:

Missing decoder.
Incorrect rule conditions.
Incorrect rule ID.
Rule priority too low.
Custom rule conflicts.

Use:

wazuh-logtest

to confirm how Wazuh interprets the event.

Duplicate Audit Alerts

Duplicate alerts usually occur when:

Multiple rules match the same event.
Multiple log sources collect identical data.
Agents forward duplicate events.
Correlation rules overlap.

Solutions include:

Reviewing rule hierarchy.
Adjusting rule conditions.
Removing duplicate collection paths.
Using rule grouping effectively.

Excessive Log Volume

High audit volume can impact:

Agent performance.
Network usage.
Indexer storage.
Dashboard responsiveness.

Optimization techniques include:

Filtering unnecessary events.
Reducing noisy audit rules.
Increasing storage capacity.
Adjusting retention settings.
Scaling Wazuh infrastructure.

Related Guide: Step-by-Step Wazuh Manager Scaling Guide

Time Synchronization Problems

Incorrect timestamps make security investigations unreliable.

Symptoms include:

Events appearing out of order.
Incorrect correlation results.
Confusing incident timelines.

Verify:

NTP configuration.
System clocks.
Time zones.
Cloud timestamp consistency.

All Wazuh components should synchronize against trusted time sources.

Indexing and Dashboard Issues

Audit logs may be collected correctly but fail to appear in the dashboard.

Possible causes:

Wazuh Indexer errors.
Failed index templates.
Storage exhaustion.
Shard allocation problems.
Dashboard connectivity issues.

Troubleshooting steps:

Check cluster health.
Review indexer logs.
Verify index availability.
Confirm dashboard connectivity.

Related Guides:

Real-World Example

A Security Operations Center (SOC) at a mid-sized enterprise manages a hybrid environment containing Linux servers, Windows endpoints, Active Directory infrastructure, and cloud workloads running across AWS and Azure.

The organization deploys Wazuh as its centralized security monitoring platform to improve threat detection, incident response, and compliance reporting.

Centralizing Audit Data Across the Environment

The SOC team begins by deploying Wazuh agents across:

Linux production servers
Employee Windows workstations
Domain Controllers
Cloud virtual machines
Critical application servers

Each environment is configured to collect security-specific audit telemetry.

For Linux systems, the team enables the Linux Audit Framework (auditd) to monitor:

Privileged command execution
Changes to authentication files
Unauthorized configuration changes
Suspicious system calls

For Windows endpoints, administrators enable Advanced Audit Policy settings to collect:

Failed authentication attempts
Account modifications
Privilege changes
Security policy updates

The team also deploys Sysmon to obtain deeper visibility into:

Process execution
PowerShell activity
Network connections
Suspicious binaries

Building Custom Audit Detection Rules

The SOC team creates custom Wazuh rules designed around the organization’s threat model.

Examples include:

Privilege Escalation Detection

A rule detects when:

A standard user executes privileged commands.
A user is added to an administrative group.
Unexpected sudo activity occurs on Linux servers.

The alert includes:

User account
Hostname
Command executed
Timestamp
Risk severity

Unauthorized Account Changes

The team monitors:

New administrator accounts.
Disabled security accounts.
Unexpected Active Directory group changes.
Cloud IAM permission modifications.

These detections help identify attackers attempting to establish persistence.

Suspicious Authentication Activity

The SOC creates correlation rules that identify:

Multiple failed logins followed by success.
Login attempts from unusual locations.
Excessive authentication failures.
Privileged account misuse.

Instead of alerting on every failed login, Wazuh correlates multiple events into higher-confidence incidents.

Critical File Modification Detection

Using Wazuh File Integrity Monitoring, the organization monitors sensitive files including:

Linux authentication configuration.
Windows system directories.
Application configuration files.
Security tool settings.

Any unexpected modification generates an alert containing the affected file, user, and change details.

Reducing Audit Noise

Initially, the SOC receives thousands of alerts daily due to routine administrative activity.

The team improves alert quality by:

Excluding known automation accounts.
Reducing low-value audit events.
Creating exceptions for approved maintenance tasks.
Increasing severity for high-risk activities.
Correlating multiple events together.

After tuning, analysts receive fewer alerts but with significantly higher investigation value.

Improving Incident Response and Compliance

With centralized Wazuh audit logging, the SOC gains complete visibility across endpoints, identity systems, and cloud infrastructure.

During investigations, analysts can quickly answer:

Which user performed an action?
Which system was affected?
What changes occurred?
When did the activity happen?
Was the behavior authorized?

The organization also uses Wazuh audit data to support:

PCI DSS evidence collection
ISO 27001 reviews
SOC 2 assessments
Internal security audits

By combining Linux auditd, Windows auditing, Sysmon, cloud audit logs, and customized Wazuh detection rules, the SOC transforms raw security events into actionable intelligence.

Centralized audit logging reduces investigation time, improves threat detection accuracy, and provides continuous visibility across the entire enterprise environment.

Frequently Asked Questions

Question: What Are Wazuh Audit Logs?

Wazuh audit logs are security-related records collected from endpoints, servers, cloud platforms, and applications that provide visibility into user activity, system changes, authentication events, and administrative actions.

Unlike standard operational logs, audit logs focus on accountability by recording:

Who performed an action
What action occurred
When the activity happened
Which system was affected
Whether the action was successful or denied

Wazuh collects, analyzes, and correlates these audit events through its agent, manager, detection rules, Wazuh Indexer, and Dashboard components.

Question: Does Wazuh Support Linux auditd?

Yes. Wazuh supports the Linux Audit Framework (auditd) and can collect audit events from Linux endpoints.

Linux auditd provides visibility into activities such as:

User authentication
Privileged command execution
File modifications
Permission changes
System calls
Security configuration changes

The Wazuh agent monitors audit log files generated by auditd and forwards events to the Wazuh manager for analysis.

Question: Can Wazuh Collect Windows Security Event Logs?

Yes. Wazuh can collect Windows Security Event Logs using the Wazuh agent’s Event Channel monitoring capabilities.

Common Windows audit events monitored by Wazuh include:

Successful and failed logins
Account creation
Password changes
Group membership changes
Privilege assignments
Security policy modifications
Process execution events

Organizations can improve Windows monitoring by combining native Security Event Logs with Sysmon telemetry and custom Wazuh detection rules.

Is Sysmon Required for Wazuh Audit Logging?

No. Sysmon is not required for Wazuh audit logging, but it is highly recommended for organizations that need deeper endpoint visibility.

Windows Security Event Logs provide important security information, while Sysmon adds additional telemetry such as:

Detailed process creation events
Command-line arguments
Network connections
Registry changes
Process injection activity
File creation events

Many security teams deploy Sysmon alongside Wazuh because it improves detection coverage for advanced attacks, malware activity, and suspicious endpoint behavior.

Question: How Do I Reduce Audit Log Noise in Wazuh?

Reducing audit log noise requires balancing visibility with operational efficiency.

Common techniques include:

Removing unnecessary audit rules.
Filtering low-value events.
Excluding trusted automation accounts.
Adjusting Wazuh rule severity levels.
Creating rule exceptions.
Using event correlation instead of individual alerts.
Monitoring only high-value systems.

Regular tuning is important because infrastructure, applications, and user behavior continuously change.

Related Guide: How to Reduce False Positives in Wazuh

Where Are Audit Logs Stored in Wazuh?

The storage location depends on the type of audit data being collected.

Common locations include:

Linux audit logs:

/var/log/audit/audit.log

Windows audit logs:

Stored within Windows Event Channels, such as:

Security

Sysmon logs:

Microsoft-Windows-Sysmon/Operational

After collection, events are processed by the Wazuh manager and indexed in the Wazuh Indexer for searching and visualization through the Wazuh Dashboard.

Related Guide: The Ultimate Wazuh Indexer Guide

Question: Can Wazuh Monitor Cloud Audit Logs?

Yes. Wazuh can collect and analyze audit logs from major cloud platforms, including:

AWS CloudTrail
Azure Activity Logs
Google Cloud Audit Logs

Cloud audit monitoring enables organizations to detect:

Unauthorized administrative actions
IAM permission changes
Suspicious API activity
Cloud resource modifications
Account compromise indicators

Combining cloud audit logs with endpoint telemetry gives security teams a complete view of activity across hybrid environments.

Question: How Do I Troubleshoot Missing Audit Events?

When audit events do not appear in Wazuh, troubleshoot the collection pipeline from the endpoint to the dashboard.

Check the following:

Confirm the audit source is generating events.
Verify the Wazuh agent service is running.
Review agent configuration files.
Confirm network connectivity with the manager.
Verify decoders are processing events correctly.
Test events using wazuh-logtest.
Check Wazuh Indexer and Dashboard availability.

Common causes include:

Incorrect log paths
Disabled auditing
Missing permissions
Incorrect event channel configuration
Decoder or rule mismatches

Related Guides:

Question: Are Wazuh Audit Logs Useful for Compliance?

Yes. Wazuh audit logs provide valuable evidence for many compliance frameworks, including:

PCI DSS
HIPAA
ISO 27001
NIST Cybersecurity Framework
SOC 2
CIS Controls

Audit logging helps organizations demonstrate:

User accountability
Security monitoring
Access control enforcement
Incident detection capabilities
Historical event tracking

However, compliance requires more than collecting logs.

Organizations must also establish appropriate retention policies, review procedures, alert workflows, and incident response processes.

Related Guide: How to Configure Wazuh Log Retention

Question: How Can I Create Custom Rules for Audit Log Events?

Custom Wazuh rules allow organizations to detect environment-specific threats and suspicious behaviors.

The process typically involves:

Identify the audit event you want to detect.
Analyze the event structure using wazuh-logtest.
Create a custom rule in local_rules.xml.
Assign an appropriate severity level.
Test the rule with sample events.
Deploy and monitor alert performance.

Custom rules can detect activities such as:

Unauthorized administrator creation
Privilege escalation
Suspicious commands
Sensitive file modifications
Abnormal authentication behavior

Conclusion

Configuring Wazuh audit logs provides organizations with the visibility required to detect threats, investigate incidents, and maintain compliance across modern hybrid environments.

By collecting security events from Linux systems, Windows endpoints, Active Directory, cloud platforms, and critical applications, Wazuh transforms raw audit data into actionable security intelligence.

The configuration process involves several key steps:

Preparing the Wazuh manager and agents.
Enabling audit sources such as Linux auditd, Windows Advanced Audit Policy, and Sysmon.
Configuring the Wazuh agent to collect audit events.
Creating and tuning detection rules.
Monitoring events through the Wazuh Dashboard.
Maintaining appropriate retention and storage strategies.

Effective audit logging requires continuous improvement.

Security teams should regularly review audit policies, tune detection rules, remove unnecessary noise, and update monitoring strategies as infrastructure changes.

The most successful Wazuh deployments treat detection engineering as an ongoing process rather than a one-time configuration task.

Regular rule testing, alert analysis, and threat intelligence updates help ensure that audit monitoring remains accurate and effective.

Organizations looking to improve their security posture should continue expanding their Wazuh capabilities by integrating additional telemetry sources, creating custom detection logic, automating response workflows, and aligning audit monitoring with industry security frameworks.

With properly configured Wazuh audit logs, security teams gain centralized visibility, faster incident investigations, stronger compliance evidence, and a more proactive approach to threat detection.

How to Configure Wazuh Audit Logs

What Are Wazuh Audit Logs?

Common Audit Log Sources Supported by Wazuh

Linux Audit Framework (auditd)

Windows Security Event Logs

Sysmon Events

Active Directory Audit Logs

Authentication Logs

File Integrity Monitoring (FIM) Events

Cloud Audit Logs (AWS CloudTrail, Azure Activity Logs, Google Cloud Audit Logs)

Prerequisites

Wazuh Manager Installation

Wazuh Agent Deployment

Administrative Privileges

Time Synchronization (NTP)

Required Ports and Network Connectivity

Basic Understanding of Wazuh Rules and Decoders

Understanding the Wazuh Audit Log Architecture

Audit Event Generation

Log Collection by the Wazuh Agent

Event Decoding

Rule Matching

Alert Generation

Indexing in the Wazuh Indexer

Visualization in the Wazuh Dashboard

How to Configure Audit Logs on Linux

Install and Enable auditd

Configure Audit Rules

Verify Audit Rule Loading

Configure the Wazuh Agent to Monitor Audit Logs

Restart Required Services

Validate Event Collection

How to Configure Audit Logs on Windows

Enable Advanced Audit Policy

Configure Windows Security Auditing

Install Sysmon (Optional but Recommended)

Configure Wazuh Agent Log Collection

Validate Windows Audit Events

Collecting Cloud Audit Logs

AWS CloudTrail Integration

Azure Activity Logs Integration

Google Cloud Audit Logs Integration

Best Practices for Centralized Cloud Auditing

Creating Custom Detection Rules for Audit Logs

Writing Custom Wazuh Rules

Matching Specific Audit Events

Severity Levels

Rule IDs and Organization

Testing Custom Rules

Reducing False Positives

Be First to Comment

Leave a Reply Cancel reply