Index

Server architecture

The Wazuh server includes the Analysis engine, Wazuh server API, agent enrollment service, agent connection service, cluster daemon, and Filebeat. It runs on Linux across physical endpoints, virtual machines, containers, or cloud instances. On Windows endpoints, deploy using Wazuh Docker.

The diagram below shows the Wazuh server architecture and components.

Server components

The Wazuh server comprises several components listed below that have different functions, such as enrolling new agents, validating each agent's identity, and encrypting the communications between the Wazuh agent and the Wazuh server.

• Agent enrollment service: Registers new Wazuh agents and generates and distributes unique authentication keys to each agent. It runs as a network service and supports TLS and SSL certificate–based authentication, or enrollment using a fixed password.

• Agent connection service: Manages communication between Wazuh agents and the Wazuh server. It validates Wazuh agent identities using enrollment keys, enforces encryption for secure data transfer, and enables centralized configuration management to push updated agent settings remotely.

• Analysis engine: At the core of Wazuh threat detection capabilities, the Analysis engine processes received security data using decoders and rules:

  • Decoders classify log types (for example, Windows events, SSH logs, web server logs) and extract relevant fields such as IP addresses, usernames, and event IDs.

  • Rules match decoded events against known patterns to detect threats and anomalies. When triggered, rules generate alerts and invoke incident response actions such as blocking IP addresses, terminating malicious processes, or removing malware artifacts.

• Wazuh server API: Provides a programmatic interface for interacting with the Wazuh server. It allows administrators using the Wazuh dashboard or command line to perform the following, but not limited to:

  • Configure and manage agents or servers

  • Monitor system health and infrastructure status

  • Query alerts and endpoint data

  • Create or update decoders and rules

To learn more, visit the Wazuh server API documentation.

• Wazuh cluster daemon: Enables horizontal scaling by linking multiple Wazuh servers into a cluster. Using a load balancer provides high availability, fault tolerance, and load distribution.

• Filebeat: Forwards events and alerts from the Wazuh analysis engine to the Wazuh indexer.

Visit the installation guide and user manual for more information about the Wazuh server.

Data visualization and analysis

The Wazuh dashboard lets users navigate security data collected from Wazuh agent and agentless devices, and alerts generated by the Wazuh server. It includes dashboards for threat hunting, malware detection, file integrity monitoring, system inventory, and regulatory compliance (for example, PCI DSS, GDPR, HIPAA, and NIST 800-53). You can generate reports and create custom visualizations and dashboards.

Agents monitoring and configuration

The Wazuh dashboard allows users to manage agent configuration and monitor agent status. For each monitored endpoint, users can define which agent modules are enabled, which log files are read, which files are monitored for integrity changes, and which configuration checks are performed.

Platform management

The Wazuh dashboard provides a user interface to manage a Wazuh deployment. This includes monitoring the status, logs, and statistics of Wazuh components, configuring the Wazuh server, and creating custom rules and decoders for log analysis and threat detection.

Developer tools

The Wazuh dashboard includes a ruleset test tool that processes log messages to show how they are decoded and whether they match a detection rule. This is useful when testing custom decoders and rules.

The Wazuh dashboard also includes API consoles for interacting with the Wazuh server and the Wazuh indexer API. They are used to manage the Wazuh server capabilities or interact with Wazuh indexer indices.

Wazuh server API

Wazuh indexer API

Agent architecture

The Wazuh agent has a modular architecture. Each module is in charge of its own tasks, including monitoring the file system, reading log files, collecting inventory data, scanning the system configuration, and looking for malware. Users can manage agent modules through configuration settings, adapting the solution to their specific use cases.

The diagram below shows the agent architecture and modules.

Wazuh agent modules

All agent modules are configurable and perform different security tasks. This modular architecture allows you to configure each module according to your security needs. The following list summarizes the purposes of the Wazuh agent modules.

• Log collector: Reads flat log files and Windows events, collecting operating system and application log messages. It supports XPath filters for Windows events and recognizes multi-line formats like Linux Audit logs. It can also enrich JSON events with additional metadata.

• Command execution: Runs authorized commands periodically, collecting their output and reporting it back to the Wazuh server for further analysis. You can use this module for different purposes, such as monitoring available disk space or getting a list of recently logged-in users.

• File integrity monitoring (FIM): Monitors the file system, reporting when files are created, deleted, or modified. It keeps track of changes in file attributes, permissions, ownership, and content. When an event occurs, it captures who, what, and when details in real time.

• Security configuration assessment (SCA): Provides continuous configuration assessment, utilizing out-of-the-box checks based on the Center of Internet Security (CIS) benchmarks. Users can also create their own SCA checks to monitor and enforce their security policies.

• System inventory: Periodically runs scans to collect inventory data such as operating system version, network interfaces, running processes, installed applications, and a list of open ports. Scan results are stored in local SQLite databases that can be queried remotely.

• Malware detection: Uses a non-signature-based approach to detect anomalies and the possible presence of rootkits. It also looks for hidden processes, hidden files, and hidden ports while monitoring system calls.

• Active Response: Runs automatic actions when threats are detected, triggering responses to block a network connection, stop a running process, or delete a malicious file. Users can also create custom responses when required, for example, responses for running a binary in a sandbox, capturing network traffic, and scanning a file with an antivirus.

• Container security monitoring: Integrates with the Docker Engine API to monitor changes in a containerized environment. For example, it detects changes to container images, network configuration, or data volumes. It alerts about containers running in privileged mode and about users executing commands in a running container.

• Cloud security monitoring: Monitors cloud providers such as Amazon Web Services, Microsoft Azure, or Google GCP, communicating natively with their APIs. It detects changes to the cloud infrastructure, for example, when a new user is created, a security group is modified, or a cloud instance is stopped. Additionally, it collects cloud services log data such as AWS CloudTrail, GCP Pub/Sub, and Azure Active Directory.

Communication with Wazuh server

The Wazuh agent communicates with the Wazuh server to ship collected data and security-related events. The Wazuh agent also sends operational data, reporting its configuration and status. Once connected, the agent can be upgraded, monitored, and configured remotely from the Wazuh server.

The communication between the Wazuh agent and the Wazuh server takes place through a secure channel (TCP or UDP), providing data encryption and compression in real time. Additionally, it includes flow control mechanisms to avoid flooding, queueing events when necessary, and protecting the network bandwidth.

You need to enroll the Wazuh agent before connecting it to the Wazuh server for the first time. This process provides the agent with a unique key used for authentication and data encryption.

Wazuh SCA module

Wazuh offers a Security Configuration Assessment (SCA) module that assists security teams to scan and detect misconfigurations within their environment. The Wazuh agent uses policy files to scan endpoints that it monitors. These files contain predefined checks to be carried out on each monitored endpoint.

Wazuh includes SCA policies out-of-the-box based on the Center for Internet Security (CIS) security benchmarks. These benchmarks serve as essential guidelines on best practices for protecting IT systems and data from cyberattacks. They provide clear instructions for establishing a secure baseline configuration and offer guidance to ensure that users implement effective measures to safeguard their critical assets and mitigate potential vulnerabilities. By adhering to these standards, you can enhance your overall security posture and mitigate the risk of cyber threats against your business.

Some other benefits of the Wazuh Security Configuration Assessment (SCA) module include:

• Security posture management: Wazuh SCA helps organizations ensure that their endpoints are configured securely. This minimizes vulnerabilities resulting from misconfigurations and reduces the risk of security breaches.

• Compliance monitoring: It allows organizations to assess and implement compliance with regulatory standards, best practices, and internal security policies.

• Continuous monitoring: Wazuh SCA continuously monitors the configuration of the endpoints and alerts when it discovers misconfigurations.

Overview of Wazuh SCA policies

The Wazuh SCA module uses policies written in YAML format. Each policy consists of checks, and each check comprises one or more rules. These rules can examine various aspects of an endpoint, such as the presence of files, directories, Windows registry keys, running processes, and more.

By default, the Wazuh agent runs scans for every policy (.yaml or .yml files) present in the ruleset directory. This directory can be found in the following locations on every operating system that runs the Wazuh agent:

• Linux and Unix-based agents: /var/ossec/ruleset/sca.

• Windows agents: C:\Program Files (x86)\ossec-agent\ruleset\sca.

• macOS agents: /Library/Ossec/ruleset/sca.

Wazuh also allows you to create custom policies that can be used to scan endpoints and verify if they conform to your organization’s policies.

See a snippet of a CIS policy file /var/ossec/ruleset/sca/cis_ubuntu22-04.yml which is included out-of-the-box on Ubuntu 22.04 endpoints. The SCA policy which is based on the CIS benchmarks, runs checks on the endpoint to determine if it conforms to the best practices for system hardening. The SCA policy with ID 28500 checks if the /tmp directory is on a separate partition.

- id: 28500
  title: "Ensure /tmp is a separate partition."
  description: "The /tmp directory is a world-writable directory used for temporary storage by all users and some applications."
  rationale: "Making /tmp its own file system allows an administrator to set additional mount options such as the noexec option on the mount, making /tmp useless for an attacker to install executable code. It would also prevent an attacker from establishing a hard link to a system setuid program and wait for it to be updated. Once the program was updated, the hard link would be broken and the attacker would have his own copy of the program. If the program happened to have a security vulnerability, the attacker could continue to exploit the known flaw. This can be accomplished by either mounting tmpfs to /tmp, or creating a separate partition for /tmp."
  impact: "Since the /tmp directory is intended to be world-writable, there is a risk of resource exhaustion if it is not bound to a separate partition. Running out of /tmp space is a problem regardless of what kind of filesystem lies under it, but in a configuration where /tmp is not a separate file system it will essentially have the whole disk available, as the default installation only creates a single / partition. On the other hand, a RAM-based /tmp (as with tmpfs) will almost certainly be much smaller, which can lead to applications filling up the filesystem much more easily. Another alternative is to create a dedicated partition for /tmp from a separate volume or disk. One of the downsides of a disk-based dedicated partition is that it will be slower than tmpfs which is RAM-based. /tmp utilizing tmpfs can be resized using the size={size} parameter in the relevant entry in /etc/fstab."
  remediation: "First ensure that systemd is correctly configured to ensure that /tmp will be mounted at boot time. # systemctl unmask tmp.mount For specific configuration requirements of the /tmp mount for your environment, modify /etc/fstab or tmp.mount. Example of /etc/fstab configured tmpfs file system with specific mount options: tmpfs 0 /tmp tmpfs defaults,rw,nosuid,nodev,noexec,relatime,size=2G 0 Example of tmp.mount configured tmpfs file system with specific mount options: [Unit] Description=Temporary Directory /tmp ConditionPathIsSymbolicLink=!/tmp DefaultDependencies=no Conflicts=umount.target Before=local-fs.target umount.target After=swap.target [Mount] What=tmpfs Where=/tmp Type=tmpfs."
  references:
    - https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/
    - https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html
  compliance:
    - cis: ["1.1.2.1"]
    - cis_csc_v7: ["14.6"]
    - cis_csc_v8: ["3.3"]
    - mitre_techniques: ["T1499", "T1499.001"]
    - mitre_tactics: ["TA0005"]
    - mitre_mitigations: ["M1022"]
    - cmmc_v2.0: ["AC.L1-3.1.1", "AC.L1-3.1.2", "AC.L2-3.1.5", "AC.L2-3.1.3", "MP.L2-3.8.2"]
    - hipaa: ["164.308(a)(3)(i)", "164.308(a)(3)(ii)(A)", "164.312(a)(1)"]
    - pci_dss_v3.2.1: ["7.1", "7.1.1", "7.1.2", "7.1.3"]
    - pci_dss_v4.0: ["1.3.1", "7.1"]
    - nist_sp_800-53: ["AC-5", "AC-6"]
    - soc_2: ["CC5.2", "CC6.1"]
  condition: all
  rules:
    - 'c:findmnt --kernel /tmp -> r:\s*/tmp\s'
    - "c:systemctl is-enabled tmp.mount -> r:generated|enabled"

The /tmp directory is used to store data that is needed for a short time by system and user applications. Mounting /tmp on a separate partition allows an administrator to set additional mount options such as the noexec, nodev, and nosuid. Therefore making the directory useless for an attacker to install executable code. The SCA policy file also gives recommendations on how to remediate this issue.

Viewing SCA results

The Wazuh dashboard has a Configuration Assessment module that allows you to view SCA scan results for each agent.

Interpreting SCA results

The image below shows the policy based on the CIS benchmark for Ubuntu Linux 22.04 LTS. You can see that 191 checks were run against the Ubuntu 22.04 endpoint. Out of these, 56 passed, 87 failed, and 48 are not applicable to the endpoint. It also shows a score of 39% which is calculated based on the number of tests passed.

You can click on the checks to get more information. In the image below, you can see information such as rationale, remediation, and a description of the check with ID 3003.

The above SCA scan result shows failed because the public key authentication for ssh is not enabled. If the remediation is implemented, the result will change to passed thereby improving the security of the endpoint.

Implementing SCA remediation steps

In the example in the previous section, implementing the remediation provided by the Wazuh SCA improves the security of the endpoint. This involves changing the PubkeyAuthentication option value in the sshd_config file. In the image below, you can see the status of the check 3003 has changed to passed.

By utilizing the Wazuh SCA module, you can detect misconfigurations, remediate them, and verify that your endpoints adhere to industry best practices. This proactive approach significantly reduces the likelihood of security breaches within your environment.

Wazuh for malware detection

Traditional methods, which rely solely on signature-based detections, have limitations and fail to capture new threats. Signature-based approaches struggle with detecting zero-day attacks, polymorphic malware, and other evasion techniques employed by threat actors. As a result, organizations are at risk of undetected breaches and data exfiltration. Wazuh empowers organizations to detect and respond to sophisticated and evasive threats effectively. Wazuh encompasses different modules that identify malware properties, activities, network connections, and more.

Detecting malicious activities with threat detection rules

Wazuh has threat detection rules that enable behavior-based malware detection. Instead of relying solely on predefined signatures, Wazuh focuses on monitoring and analyzing abnormal behavior exhibited by malware. This allows Wazuh to detect known and previously unknown threats. This way, Wazuh provides a proactive and adaptable defense against cyber threats. Wazuh has out-of-the-box rulesets that are specifically designed to trigger alerts for recognized malware patterns, providing a quick response to potential security incidents. For example, the image below shows an alert with rule ID 92213 triggered when an executable is dropped in a folder commonly used by malware. This alert prompts security teams to begin the investigation and remediation process.

Wazuh allows users to create custom rules for more flexibility in detection, empowering them to focus on relevant activities, and optimizing malware detection. Wazuh decodes and organizes logs from monitored endpoints into fields, which can then be utilized to create custom rules for alerting when malicious activity is detected.

Wazuh rules use multiple fields that denote indicators of compromise (IOCs) to reduce false positives and detect known malware based on specific behaviors. These rules can connect related malware activities, such as intrusion, privilege escalation, lateral movement, obfuscation, and exfiltration for comprehensive detection.

Below is an example of some Wazuh custom rules created to alert on malicious activities of the LimeRAT malware:

<group name="lime_rat,sysmon,">

  <!-- Rogue create netflix.exe creation -->
  <rule id="100024" level="12">
    <if_sid>61613</if_sid>
    <field name="win.eventdata.image" type="pcre2">\.exe</field>
    <field name="win.eventdata.targetFilename" type="pcre2">(?i)[c-z]:\\\\Users\\\\.+\\\\AppData\\\\Roaming\\\\checker netflix\.exe</field>
    <description>Potential LimeRAT activity detected: checker netflix.exe created at $(win.eventdata.targetFilename) by $(win.eventdata.image).</description>
    <mitre>
      <id>T1036</id>
    </mitre>
  </rule>

  <!-- Registry key creation for persistence -->
  <rule id="100025" level="12">
    <if_group>sysmon</if_group>
    <field name="win.eventdata.details" type="pcre2">(?i)[c-z]:\\\\Users\\\\.+\\\\AppData\\\\Roaming\\\\checker netflix\.exe</field>
    <field name="win.eventdata.targetObject" type="pcre2" >HKU\\\\.+\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\checker netflix\.exe</field>
    <field name="win.eventdata.eventType" type="pcre2" >^SetValue$</field>
    <description>Potential LimeRAT activity detected:  $(win.eventdata.details) added itself to the Registry as a startup program $(win.eventdata.targetObject) to establish persistence.</description>
    <mitre>
      <id>T1547.001</id>
    </mitre>
  </rule>

  <!-- Network activity detection -->
  <rule id="100026" level="12">
    <if_sid>61605</if_sid>
    <field name="win.eventdata.image" type="pcre2">(?i)[c-z]:\\\\Users\\\\.+\\\\AppData\\\\Roaming\\\\checker netflix\.exe</field>
    <description>Potential LimeRAT activity detected: Suspicious DNS query made by $(win.eventdata.image).</description>
    <mitre>
      <id>T1572</id>
    </mitre>
  </rule>


  <!-- LimeRAT service creation -->
  <rule id="100028" level="12">
    <if_sid>61614</if_sid>
    <field name="win.eventdata.targetObject" type="pcre2" >HKLM\\\\System\\\\CurrentControlSet\\\\Services\\\\disk</field>
    <field name="win.eventdata.eventType" type="pcre2" >^CreateKey$</field>
    <description>Potential LimeRAT activity detected: LimeRAT service $(win.eventdata.targetObject) has been created on $(win.system.computer).</description>
      <mitre>
    <id>T1543.003</id>
      </mitre>
  </rule>

</group>

These rules create alerts that are visible in the Threat Hunting module on the Wazuh dashboard.

Refer to the blog post on LimeRat detection and response with Wazuh for the full configuration.

Wazuh identifies behavior indicative of malware, it generates real-time alerts and notifications, enabling security teams to respond swiftly and mitigate potential risks before they escalate.

Leveraging file integrity monitoring for detecting malware activity

File Integrity Monitoring (FIM) is a valuable component in malware detection. Wazuh provides FIM capabilities to monitor and detect changes to files and directories on monitored endpoints. These changes include creation, modification, or deletion. While FIM provides essential insights, combining it with other capabilities and integrations further enhances its effectiveness for malware detection. Wazuh allows security teams to create custom rules based on FIM events, enabling targeted malware detection. These customizable rules correlate FIM events with specific indicators of compromises such as suspicious file extensions, code snippets, or known malware signatures.

The image below shows an alert when a web shell creates or modifies a file on a web server.

Malware frequently targets Windows Registry to achieve malicious objectives, such as establishing persistence and performing other malicious actions. The Wazuh File Integrity Monitoring (FIM) module includes Windows Registry monitoring that monitors commonly targeted registry paths to detect modifications. When changes occur, the FIM module triggers real-time alerts, empowering security teams to swiftly identify and respond to suspicious registry key manipulation.

The images below display the Wazuh FIM module dashboard and events of Windows Registry modifications.

Enhancing malware detection with threat intelligence integration

Users can boost their malware detection capabilities by integrating with threat intelligence sources. These intelligence feeds enrich the Wazuh knowledge base with additional up-to-date information on known malicious IP addresses, domains, URLs, and other indicators of compromise. Examples of threat intelligence sources Wazuh can integrate with include VirusTotal, MISP, and more.

Wazuh proactively identifies malicious files by comparing the identified IOCs with the information stored in the CDB lists (constant databases). These lists can store known malware indicators of compromise (IOCs) including file hashes, IP addresses, and domain names.

You can customize entries in either key:value or key: format for tailored detection, an example of such is seen below. A CBD list containing known MD5 malware hashes of the Mirai and Xbash malware is used for detection:

e0ec2cd43f71c80d42cd7b0f17802c73:mirai
55142f1d393c5ba7405239f232a6c059:Xbash

Upon detection, these alerts are observed within the Threat Hunting module of the Wazuh dashboard, as seen below.

Refer to the Use case: Detecting malware using file hashes in a CDB list for full configurations.

** Alert 1668497750.1838326: - ossec,rootcheck,pci_dss_10.6.1,gdpr_IV_35.7.d,
2022 Nov 15 09:35:50 (Ubuntu) any->rootcheck
Rule: 510 (level 7) -> 'Host-based anomaly detection event (rootcheck).'
Rootkit 't0rn' detected by the presence of file '/usr/bin/.t0rn'.
title: Rootkit 't0rn' detected by the presence of file '/usr/bin/.t0rn'.

Monitoring system calls for malware and anomaly detection

Wazuh monitors system calls on Linux endpoints to bolster malware detection and aid in anomaly detection. Wazuh utilizes the Linux Audit system to monitor system calls.

System call monitoring in combination with Wazuh File Integrity Monitoring (FIM) and threat intelligence integration enhances malware detection. It captures security-relevant events like file access, command execution, and privilege escalation, providing real-time insights into potential security incidents. This comprehensive approach strengthens organizations' cybersecurity resilience. In the image below, you can visualize the alerts for privilege abuse on the Wazuh dashboard for Ubuntu Linux 22.04.

Wazuh empowers security teams to leverage the audit rules provided by Auditd. Creating custom rules based on system call events enhances malware detection efforts and strengthens overall cybersecurity resilience.

Viewing File Integrity Monitoring scan results

You can find a dedicated File Integrity Monitoring module in the Wazuh dashboard where all file integrity events triggered from monitored endpoints are reported. This increases visibility as it provides valuable information on the status of monitored directories and their potential impact on the security posture. The Wazuh FIM dashboard has three different sections to view FIM analysis results; Inventory, Dashboard, and Events.

1. The Inventory section displays a list of all files that the FIM module has indexed. Each file has entry information including the filename, last modification date, user, user ID, group, and file size.

   

2. The Dashboard section shows an overview of the events triggered by the FIM module for all monitored endpoints. You can also streamline it to show the events for a selected monitored endpoint.

   

3. The Events section shows the alerts triggered by the FIM module. It displays details such as the agent name, the file path of the monitored file, the type of FIM event, a description of the alert, and the rule level of each alert.

   

Below are common use cases the Wazuh FIM module would assist you in monitoring within your environment.

Monitoring file integrity

Modifications to configuration files and file attributes are frequent occurrences within endpoints in an IT infrastructure. However, if not validated, there may be unauthorized and inadvertent changes that could affect the behavior of the endpoints or the applications running in them. The Wazuh FIM module runs periodic scans on specific files and directories to detect file changes in real time. It scans the designated files to create a baseline of the current state. It checks for file modifications by comparing checksums and attribute values to the baseline, generating alerts if discrepancies are found.

The Wazuh FIM module supports various configuration options that enable effective monitoring of assets:

• Real-time monitoring: The FIM module provides a realtime attribute that enables continuous monitoring of specified directories. This feature is particularly useful for monitoring critical directories and tracking changes immediately after they occur. Wazuh allows you to specify the directories or files in the monitored endpoints that would be reported in real-time if file changes occur.

• Scheduled monitoring: The frequency option in the Wazuh FIM module allows users to customize the scheduling of each FIM scan performed in your monitored endpoints. The default scan interval for the FIM module is 12 hours (43200 seconds) and can be customized on each endpoint. Alternatively, scans can be scheduled using the scan_time and the scan_day options. These options help users to set up FIM scans outside business hours or during holidays.

• Who-data monitoring: Wazuh captures advanced insights into file changes using the who-data functionality. This functionality uses audit tools like the Linux Audit subsystem and Microsoft Windows SACL to determine important information about the detected file changes. The who-data monitoring functionality allows the FIM module to obtain information on when the change event occurred, who or what made the change, and what content was changed. This is useful in maintaining accountability and validating if changes made to monitored files or directories were authorized and performed using approved processes.

  Below is an example of an alert generated when a monitored file is changed on a Windows endpoint.

  

  In alert fields, the who-data metadata shows that the user wazuh added the word Hello to the audit_docu.txt file using the Notepad.exe process.

  

• Reporting changes in file values: The FIM module provides a report_changes attribute that records and reports the exact content changed in a text file to the Wazuh server. The attribute enables the Wazuh agent to make copies of monitored files to a private location on each endpoint for further review. This monitoring option is helpful when users want to initiate specific responses when file changes in monitored directories match the behavior of known malicious activities. For example, the alert below indicates when Wazuh detects the creation of a web shell scripting file webshell-script.php in a monitored directory.

  

• Recording file attributes: Users can configure the FIM module to record specific attributes of a monitored file. Wazuh supports various file attributes that users can use to specify the file metadata that the FIM module will record or ignore. For example, this monitoring option would be useful when users want to record only the SHA-256 hash of a configuration file, excluding other hash types.

Detecting and responding to malware

The Wazuh FIM module integrates with other Wazuh capabilities and third-party threat intelligence solutions to create a comprehensive security monitoring environment. This is imperative to enhance malware detection and response capabilities, ensuring robust defense against cyber threats.

The Wazuh FIM module supports various integrations, including but not limited to:

• File integrity monitoring and YARA: By combining the Wazuh FIM module and the YARA tool, it is possible to detect malware when suspicious file additions or modifications are identified. The YARA rule files contain samples of malware indicators that are downloaded to the monitored endpoints. When the FIM module detects a change in the monitored file or directory, it executes a YARA scan using a script to determine if it is malware. If the YARA rule finds a match with a file, it will send the scan results to the Wazuh server for decoding and alerting. This would be reported according to the custom rule and decoder configurations configured on the Wazuh server. Check this documentation for more information on how to integrate the Wazuh FIM module with YARA.

• File integrity monitoring and VirusTotal: The Wazuh Integrator module connects to external APIs and alerting tools such as VirusTotal. The VirusTotal integration uses the VirusTotal API to detect malicious file hashes within the files and directories monitored by the FIM module. Once enabled, when FIM generates alerts, Wazuh initiates the VirusTotal integration to extract the hash value associated with the flagged file from the alert. The VirusTotal API is then used to compare these hashes against its scanning engines for potentially malicious content.

• File integrity monitoring and Active Response: The Wazuh Active Response module automatically responds to threats identified in a timely manner. This combination enables the FIM module to not only detect but also respond to malicious activities. You can configure active response scripts to execute when the FIM module detects file changes in your monitored environment. Additionally, it also generates alerts for the response performed. This reduces the Mean Time To Respond (MTTR) as malicious changes detected are remediated in a timely manner.

  In the image below Wazuh triggers when a file is added to the monitored endpoint. The VirusTotal API scans the file and identifies it as malicious content on 55 engines. Then the Wazuh Active Response module acts immediately to remove the threat from the monitored endpoint.

  

• File integrity monitoring and CDB list: Wazuh FIM module also detects malicious files by checking the presence of known malware signatures when combined with CDB lists (constant database). CDB lists are used to store known malware indicators of Compromise (IOCs) such as file hashes, IP addresses, and domain names. When CDB lists are created, Wazuh checks if field values from FIM alerts such as file hash match the keys stored in the CDB lists. If matched, it generates an alert and response based on how you configure your custom rule.

  

Monitoring Windows Registry

The Wazuh FIM module periodically scans Windows Registry entries, stores its checksums and attributes in a local database, and alerts when changes in registry values are detected. This would keep users informed about registry modifications resulting from user activities or software installations whether malicious or not.

You can configure the Wazuh open source FIM module to monitor Windows Registry values using various configuration options. The report_changes attribute in the windows_registry option provides a granular breakdown of modification detected in the monitored Windows Registry value. You can configure which Windows Registry attributes the module would record or ignore. For example, you can choose to record the check_sha1sum attribute and ignore the check_md5sum attribute, if your CDB list only contains SHA1 hashes of malicious files.

The image below shows the event of a modified Windows registry value in a monitored endpoint.

The alert when expanded shows the modified field.

Threat actors maintain persistence by commonly adding programs for their malicious activities to the Run and RunOnce keys in the Registry. Additionally, Wazuh detects any suspicious programs added to the startup registry keys. This allows you to take appropriate action to remove them before they cause harm to your system.

Meeting regulatory compliance

Meeting regulatory compliance requirements is an important consideration for organizations in various industries. File integrity monitoring is a requirement for achieving compliance with regulations such as PCI DSS, SOX, HIPAA, NIST SP 800-53, among others.

You can customize the Wazuh FIM module to monitor specific files and directories where your organization’s sensitive and confidential data are stored. Wazuh provides a comprehensive report that outlines the changes made to the files and directories being monitored. This feature is particularly useful for ensuring compliance with various regulatory standards.

For example, organizations can meet the CM-3 Configuration change control requirement in NIST SP 800-53 standard by using Wazuh. The control requires organizations to protect information at rest and monitor configuration changes in their infrastructure. The image below shows an event generated when the permissions for Uncomplicated Firewall (UFW) rule files are modified on a monitored endpoint.

Log data analysis

Effective log data collection and analysis are essential for enhancing your threat hunting methodology. You can leverage the robust capabilities of Wazuh to optimize your threat hunting efforts.

Wazuh as a unified XDR and SIEM platform offers centralized log data collection, allowing gathering of data from diverse sources such as endpoints, network devices, and applications. This centralized approach simplifies analysis and reduces the effort required to monitor multiple sources.

The image below shows the configuration settings on the Wazuh dashboard for collecting audit logs from a monitored endpoint.

Wazuh uses decoders to extract meaningful information from log data obtained from various sources. It breaks down raw log data into individual fields or attributes, such as timestamp, source IP address, destination IP address, event type, and others. The Index patterns tab on the Wazuh dashboard shows the wazuh-alerts-* index pattern and its fields.

Wazuh offers agentless monitoring and syslog log collection for efficient log data handling. It ensures consistency and compatibility across various log formats. Wazuh indexing and querying capabilities facilitate quick search and access to specific log data, streamlining analysis and investigation. Wazuh uses its advanced parsing and real-time analysis to enhance threat hunting by proactively identifying and mitigating risks thereby enhancing security.

Wazuh archives

Wazuh provides a centralized storage location for archiving all collected logs from monitored endpoints. The Wazuh archives logs include those that do not trigger alerts on the Wazuh dashboard. Wazuh archives are disabled by default and can be easily enabled. The availability of detailed logs is crucial for effective threat hunting, providing comprehensive visibility into your environment.

Wazuh archives provide log retention, indexing, and querying capabilities that give concrete visibility to analyze events within specific monitored endpoints in your environment. This facilitates uncovering event causes, event locations, event communications, event timestamps, and related parent-child processes. The image below shows the archived logs in the Discover section on the Wazuh dashboard.

MITRE ATT&CK mapping

The MITRE ATT&CK framework offers a standardized approach to mapping and understanding cyber attack tactics, techniques, and procedures (TTPs). By utilizing the Wazuh MITRE ATT&CK module, we can enhance our understanding of TTPs used by threat actors and proactively defend against them.

The Wazuh MITRE ATT&CK module maps TTPs to generated events, facilitating efficient threat hunting by promptly identifying patterns in attacker behavior. For instance, a suspicious login attempt can be associated with the “Credential Stuffing” technique in the MITRE ATT&CK framework. This empowers users to assess the frequency of such attacks and implement necessary measures to mitigate risks, such as enabling multi-factor authentication or rate-limiting login attempts. The MITRE ATT&CK module on the Wazuh dashboard allows you to view various techniques found within a monitored environment.

This module generates reports and visualizations on the Wazuh dashboard, showcasing the frequency and severity of attacks utilizing specific TTP. These reports help track compliance with security standards and regulations while highlighting areas where security measures may require strengthening. The Wazuh MITRE ATT&CK module on the Wazuh dashboard has a customizable dashboard that displays an overview of TTPs found within a monitored environment as seen below.

You can proactively protect your systems and data by leveraging insights from the MITRE ATT&CK framework. The integration of MITRE ATT&CK with Wazuh significantly enhances threat hunting and improves overall security.

Third-party integration

Wazuh integrates with third-party solutions that enhance threat hunting capabilities. These integrations enable users to consolidate data from diverse sources and automate threat detection and response. Wazuh seamlessly integrates with popular open source platforms like VirusTotal, AlienVault, URLHaus, MISP, and many others. This integration allows users to cross-reference telemetry with threat intelligence feeds, improving detection and response to threats.

Third-party integrations play a crucial role in proactive threat hunting, encompassing threat intelligence and a range of collaborative tools. These integrations provide essential insights into both established and emerging threats, enabling a comprehensive and forward-looking approach to threat detection. By promoting the exchange of information among seasoned security teams, these integrations foster a collective defense strategy, enhancing the effectiveness of the overall threat hunting process.

Some third-party solutions that Wazuh integrates with to aid threat hunting are:

• VirusTotal: Integrating VirusTotal enhances threat detection by leveraging the VirusTotal malware database for accurate identification and faster incident response. The image below shows malware detection via the VirusTotal integration.

  

• URLHaus: Integrating URLHaus by abuse.ch with Wazuh amplifies threat intelligence capabilities, empowering users to proactively detect and block malicious URLs in real-time.

• MISP: We can enrich Wazuh alerts by automating identifications of IOCs and integrating MISP with Wazuh.

Wazuh integrates with other tools that aid threat hunting beyond the above-mentioned. It supports third-party integrations for threat intelligence platforms, SIEMs, and messaging platforms using APIs and other integration methods.

Rules and decoders

Wazuh enhances threat hunting with robust rules, decoders, and pre-configured rules for diverse attack vectors and cyber activities.

The Rules module on the Wazuh dashboard presents both default and custom rules, covering a broad array of security events, including system anomalies, malware detection, authentication failures, and other potential threats as seen below.

Wazuh allows you to customize and create your own rules and decoders, tailored to your specific environment and threat landscape. This enables you to fine-tune detection, address unique requirements, and minimize blind spots.

Wazuh decoders play a vital role in normalizing and parsing diverse log formats and data sources. They ensure that collected information is presented in a standardized manner, facilitating effective analysis and correlation of data from various sources.

The Decoders module on the Wazuh dashboard allows you to view default and custom decoders. The image below shows details of the default decoder agent-upgrade.

Leveraging Wazuh rules and decoders, security teams attain actionable insights, enabling them to swiftly detect IOCs, anomalous behavior, and potential breaches.

Refer to the Wazuh ruleset documentation for detailed guidance on configuring custom rules and decoders.

Log data collection

Wazuh collects logs from a wide range of sources, enabling comprehensive monitoring of various aspects of your IT environment. You can check our documentation on Log data collection to understand better how Wazuh collects and analyzes logs from monitored endpoints. Some of the common log sources supported by Wazuh include:

• Operating system logs: Wazuh collects logs from several operating systems, including Linux, Windows, and macOS.

  Wazuh can collect syslog, auditd, application logs, and others from Linux endpoints.

  Wazuh collects logs on Windows endpoints using the Windows event channel and Windows event log format. By default, the Wazuh agent monitors the System, Application, and Security Windows event channels on Windows endpoints. The Wazuh agent offers the flexibility to configure and monitor other Windows event channels.

  Wazuh utilizes the unified logging system (ULS) to collect logs on macOS endpoints. The macOS ULS centralizes the management and storage of logs across all the system levels.

  The image below shows an event collected from the Microsoft-Windows-Sysmon/Operational event channel on a Windows endpoint.

  

• Syslog events: Wazuh gathers logs from syslog-enabled devices, encompassing a wide array of sources including Linux/Unix systems and network devices that do not support agent installation. The image below shows an alert triggered when a new user is created on the Linux endpoint and the log is forwarded to the Wazuh server via rsyslog.

  

• Agentless monitoring: The Wazuh agentless monitoring module monitors endpoints that don't support agent installation. It requires an SSH connection between the endpoint and the Wazuh server. The Wazuh agentless monitoring module monitors files, directories, or configurations and runs commands on the endpoint. The image below is an alert from an agentless device on the Wazuh dashboard.

  

• Cloud provider logs: Wazuh integrates with cloud providers like AWS, Azure, Google Cloud, and Office 365 to collect logs from cloud services such as EC2 instances, S3 buckets, Azure VMs, and more. The image below shows the CLOUD SECURITY section in the Wazuh dashboard.

  

• Custom logs: You can configure Wazuh to collect and parse logs from several applications and third-party security tools like VirusTotal, Windows Defender, and ClamAV. The image below shows an alert of a log from VirusTotal processed by the Wazuh server.

  

Rules and decoders

Wazuh rules and decoders are core components in log data analysis and threat detection and response. Wazuh provides a powerful platform for log data analysis, allowing organizations to enhance their security posture by promptly detecting and responding to potential security threats.

Wazuh decoders are responsible for parsing and normalizing log data collected from various sources. Decoders are essential for converting the raw log data in several formats into a unified and structured format that Wazuh can process effectively. Wazuh has pre-built decoders for common log formats such as syslog, Windows event channel, macOS ULS, and more. Additionally, Wazuh allows you to define custom decoders for parsing logs from specific applications or devices with unique log formats. By using decoders, Wazuh can efficiently interpret log data and extract relevant information, such as timestamps, log levels, source IP addresses, user names, and more. As shown below, you can view Wazuh out-of-the-box and custom decoders on the Server management > Decoders of the Wazuh dashboard.

Wazuh ruleset detects security events and anomalies in log data. These rules are written in a specific format and they trigger alerts when certain conditions are met. The rules are defined based on certain criteria like log fields, values, or patterns to match specific log entries that may indicate security threats. Wazuh provides a wide range of pre-built rules covering common security use cases. Additionally, administrators can create custom rules tailored to their specific environment and security requirements. The Server management category of the Wazuh dashboard lets you view the default and custom Rules.

For example, the rule below includes a match field used to define the pattern that the rule looks for. The rule also has a level field that specifies the priority of the resulting alert. Additionally, rules enrich events with technique identifiers from the MITRE ATT&CK framework and map them to regulatory compliance controls.

<rule id="5715" level="3">
  <if_sid>5700</if_sid>
  <match>^Accepted|authenticated.$</match>
  <description>sshd: authentication success.</description>
  <mitre>
    <id>T1078</id>
    <id>T1021</id>
  </mitre>
  <group>authentication_success,gdpr_IV_32.2,gpg13_7.1,gpg13_7.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,pci_dss_10.2.5,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>

Log data indexing and storage

The Wazuh indexer is a highly scalable, distributed real-time search and analytics engine. The Wazuh indexer is critical in log analysis as it stores and indexes alerts generated by the Wazuh server. These alerts are stored as JSON documents.

The Wazuh indexer guarantees redundancy by storing the JSON documents across several containers called shards and distributing the shards across multiple nodes. This implementation prevents downtime when hardware failures or cyber-attacks occur and increases query capacity as nodes are added to a cluster.

Wazuh uses four indices to store several event types:

• wazuh-alerts stores alerts generated by the Wazuh server when an event triggers a rule with high enough priority. The image below shows alerts in the Discover module of the Wazuh dashboard. The index pattern is set to wazuh-alerts-* by default.

  

• wazuh-archives index stores all events received from the Wazuh server regardless of whether they trigger an alert. The Wazuh archives use this index to enable log retention and querying capabilities that offer deeper insight into events happening within monitored endpoints. Wazuh archives are disabled by default because of the huge storage requirements needed to store all the logs. The image below shows archived events in the Discover section of Wazuh dashboard with the index pattern set to wazuh-archives-*.

  

• wazuh-monitoring index stores data about the state of Wazuh agents over a period of time. The state of the agent could be Active, Disconnected, or Never connected. This information is very useful in tracking Wazuh agents that are not reporting for several reasons that need investigation. The image below shows the connection status of the agents on the Wazuh dashboard. The agent information as shown in the image is collected from the wazuh-monitoring index.

  

• wazuh-statistics index stores performance data related to the Wazuh server. This information is critical to ensuring the Wazuh server performs optimally with the available computing resources. The image below shows performance-related events on the Wazuh dashboard.

  

Log data querying and visualization

The Wazuh dashboard offers log data querying and visualization capabilities. You can leverage the dashboard’s intuitive interface to conduct complex searches and queries to extract meaningful insights from the log data collected by Wazuh.

Wazuh provides a set of predefined dashboards and visualizations out of the box, specifically tailored to security monitoring and compliance use cases. These dashboards provide insight into common security events such as failed logins, malware detection, and system anomalies. You can further customize these dashboards to suit your specific needs and requirements. Below is a sample image of the Security event dashboard showing several interesting information like Top 5 PCI DSS Requirements, Top 5 alerts, and Alert groups evolution.

The Wazuh dashboard enables users to explore log entries in real time, apply various filters, and drill down into specific events or time ranges. This flexibility allows security analysts to identify trends, anomalies, and potential security incidents within their environment.

Wazuh allows users to create customized dashboards that display key performance indicators, security metrics, and real-time monitoring of critical systems and applications. Users can assemble multiple visualizations, such as pie charts, line graphs, and heat maps, onto a single dashboard, providing a holistic view of their infrastructure's security posture. The following blog posts detailed how to query and create custom dashboards:

• Monitoring macOS resources with Wazuh

• Monitoring Linux resources with Wazuh

• Monitoring Windows resources with Performance Counters

Achieve comprehensive visibility

The Vulnerability Detection module generates alerts for vulnerabilities discovered on the operating system and applications installed on the monitored endpoint. It correlates the software inventory collected by the Wazuh agent with the vulnerability content documents and displays the alert generated on the Wazuh dashboard. This provides a clear and comprehensive view of vulnerabilities identified in all monitored endpoints, allowing you to view, analyze and fix vulnerabilities.

The vulnerability detection dashboard shows the frequency of occurrences in different categories such as package name, operating system, agent name, vulnerability ID, and alert severity. This allows analysts to direct their focus appropriately.

You can view the alerts generated on the dashboard when new vulnerabilities are discovered.

The alerts generated on the dashboard could also be a result of remediation activities. The image below shows alerts generated after an upgrade or an uninstallation of a package resolved a vulnerability.

Obtain actionable intelligence from vulnerability alerts

Wazuh vulnerability alerts contain relevant information about the identified vulnerability which can help users understand and decide on remediation steps. You can see an example of a vulnerability detection alert below:

{
 "_index": "wazuh-alerts-4.x-sample-threat-detection",
 "_id": "e2ffSY8Be9PWdpLhA_nt",
 "_version": 1,
 "_score": null,
 "_source": {
   "predecoder": {},
   "cluster": {
     "name": "wazuh"
   },
   "agent": {
     "ip": "197.17.1.4",
     "name": "Centos",
     "id": "005"
   },
   "manager": {
     "name": "wazuh-server"
   },
   "data": {
     "vulnerability": {
       "severity": "Medium",
       "package": {
         "condition": "Package less or equal than 2.1.7.3-2",
         "name": "cryptsetup",
         "version": "2:1.6.6-5ubuntu2.1",
         "architecture": "amd64"
       },
       "references": [
         "http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html",
         "http://www.openwall.com/lists/oss-security/2016/11/14/13",
         "http://www.openwall.com/lists/oss-security/2016/11/15/1",
         "http://www.openwall.com/lists/oss-security/2016/11/15/4",
         "http://www.openwall.com/lists/oss-security/2016/11/16/6",
         "http://www.securityfocus.com/bid/94315",
         "https://gitlab.com/cryptsetup/cryptsetup/commit/ef8a7d82d8d3716ae9b58179590f7908981fa0cb",
         "https://nvd.nist.gov/vuln/detail/CVE-2016-4484",
         "http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-4484.html",
         "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4484"
       ],
       "cve_version": "4.0",
       "assigner": "cve@mitre.org",
       "published": "2017-01-23",
       "cwe_reference": "CWE-287",
       "title": "CVE-2016-4484 on Ubuntu 16.04 LTS (xenial) - low.",
       "rationale": "The Debian initrd script for the cryptsetup package 2:1.7.3-2 and earlier allows physically proximate attackers to gain shell access via many log in attempts with an invalid password.",
       "cve": "CVE-2016-4484",
       "state": "Fixed",
       "bugzilla_references": [
         "https://launchpad.net/bugs/1660701"
       ],
       "cvss": {
         "cvss2": {
           "base_score": "7.200000",
           "vector": {
             "integrity_impact": "complete",
             "confidentiality_impact": "complete",
             "availability": "complete",
             "attack_vector": "local",
             "access_complexity": "low",
             "authentication": "none"
           }
         },
         "cvss3": {
           "base_score": "6.800000",
           "vector": {
             "user_interaction": "none",
             "integrity_impact": "high",
             "scope": "unchanged",
             "confidentiality_impact": "high",
             "availability": "high",
             "attack_vector": "physical",
             "access_complexity": "low",
             "privileges_required": "none"
           }
         }
       },
       "updated": "2017-01-26"
     }
   },
   "@sampledata": true,
   "rule": {
     "firedtimes": 290,
     "mail": false,
     "level": 7,
     "pci_dss": [
       "11.2.1",
       "11.2.3"
     ],
     "tsc": [
       "CC7.1",
       "CC7.2"
     ],
     "description": "CVE-2016-4484 affects cryptsetup",
     "groups": [
       "vulnerability-detector"
     ],
     "id": "23504",
     "gdpr": [
       "IV_35.7.d"
     ]
   },
   "location": "vulnerability-detector",
   "id": "1580123327.49031",
   "decoder": {
     "name": "json"
   },
   "timestamp": "2024-05-05T17:44:08.518+0000"
 },
 "fields": {
   "data.vulnerability.published": [
     "2017-01-23T00:00:00.000Z"
   ],
   "data.vulnerability.updated": [
     "2017-01-26T00:00:00.000Z"
   ],
   "timestamp": [
     "2024-05-05T17:44:08.518Z"
   ]
 },
 "highlight": {
   "manager.name": [
     "@opensearch-dashboards-highlighted-field@wazuh-server@/opensearch-dashboards-highlighted-field@"
   ],
   "rule.groups": [
     "@opensearch-dashboards-highlighted-field@vulnerability-detector@/opensearch-dashboards-highlighted-field@"
   ]
 },
 "sort": [
   1714931048518
 ]
}

As you can see above, the alert contains key information about the detected vulnerability. This information includes the CVE information, reference links for further research, and a description that provides a concise explanation of the vulnerability.

Track vulnerability remediation

The Wazuh Vulnerability Detection module also allows you to confirm when a vulnerability has been remediated. This feature detects when a patch or software upgrade resolves a previously detected vulnerability. The feature is enabled using the hotfixes option and is available for Windows endpoints.

Use vulnerability reports to identify critical security issues

Wazuh provides users with the ability to download a report that contains security events related to discovered and resolved vulnerabilities. This feature allows users to identify endpoints with unresolved vulnerabilities and keep track of remediation activities.

Wazuh Active Response module

The Wazuh Active Response module allows users to run automated actions when incidents are detected on endpoints. This improves an organization's incident response processes, enabling security teams to take immediate and automated actions to counter detected threats.

You can also configure the actions to be either stateless or stateful. Stateless active responses are one-time actions while stateful responses revert their actions after some time.

Automating incident response with Wazuh

To leverage the Wazuh Active Response module, you need to configure the action to be carried out when a specific event occurs on a monitored endpoint. For example, you can configure the Wazuh Active Response module to delete a malicious executable from an infected endpoint. In the examples that follow, we show how the Wazuh Active Response module handles different incidents.

Removing malware

You can use the Wazuh Active Response module in conjunction with the File Integrity Monitoring module and VirusTotal integration to detect and remove malicious files from an endpoint.

The image below shows the following activities:

1. Rule ID 554 is fired when a file is added to the Downloads directory which is monitored with the Wazuh File Integrity Monitoring module.

2. Rule ID 87105 triggers when Wazuh extracts the file hash, requests data about the file hash from the VirusTotal database via its API, and receives a malicious file response.

3. Rule ID 553 is fired when a file is deleted from the Downloads directory which is monitored with the Wazuh File Integrity Monitoring module.

4. Rule ID 110006 is fired when the Wazuh Active Response module deletes the malicious file from the endpoint.

In this scenario, the Wazuh Active Response module automatically removes the malicious file, reducing the time between threat detection and mitigation.

Responding to DoS attacks

The primary goal of a DoS attack is to render the target inaccessible to legitimate users, causing a denial of service. In the image below, we show how the Wazuh Active Response module blocks malicious IP addresses performing a DoS against a web server on an Ubuntu endpoint.

In this case, the Wazuh Active Response module automatically blocks the malicious hosts from causing a DoS attack on the web server. Thereby ensuring the availability of the web server to the authorized users.

Disabling a user account after a brute-force attack

Account lockout is a security measure used to defend against brute force attacks by limiting the number of login attempts a user can make within a specified time. We use the Wazuh Active Response module to disable the user account whose password is being guessed by an attacker.

In the image below, the Wazuh Active Response module disables the account on a Linux endpoint and re-enables it again after 5 minutes.

In this scenario, when an attacker tries to guess a user's password repeatedly and fails, the account becomes temporarily inaccessible. This impedes attackers who rely on brute-force methods to guess user account passwords.

By utilizing the Wazuh Active Response module, security teams can automate responses to different incidents. Thereby ensuring efficient incident response and a more resilient cybersecurity posture.

PCI DSS

PCI DSS (Payment Card Industry Data Security Standard) outlines the security criteria that businesses that process, store, and transmit card data must adhere to. This standard is designed to tighten security measures surrounding cardholder data and lessen fraud within the payment card industry.

Payment card industries can leverage Wazuh capabilities to reinforce PCI DSS adherence. Users can customize these capabilities to align with specific business needs as stipulated by the standard. For example, you can use Wazuh to conduct a PAN scan by creating customs rules that detect the presence of an unmasked Primary Account Number(PAN).

You can find more information on how Wazuh helps organizations meet the PCI DSS standard.

GDPR

The General Data Protection Regulation (GDPR), developed by the European Union, aims to harmonize data privacy laws throughout the continent. The protection of the data of citizens of the European Union is its main priority. The GDPR framework intends to enhance user data privacy and change how the European Union, and organizations that process EU citizens data handle data privacy.

Wazuh comes with default rules and decoders to identify different kinds of cyberattacks, misconfigured systems, security vulnerabilities, and policy violations. These events are tagged to the relevant GDPR requirements. You can find more information on how Wazuh helps organizations meet the GDPR regulatory compliance.

HIPAA

The Health Insurance Portability and Accountability Act is a legal framework that enables healthcare institutions and organizations to prevent the unauthorized disclosure of sensitive patient health information. The Health Insurance Portability and Accountability Act (HIPAA) sets guidelines and procedures for processing health information to increase the efficiency of healthcare services. It entails guidelines for electronic healthcare transactions and standards for security and distinctive health identification.

The HIPAA framework requires federal privacy protections for health information due to technological advancements, which have an influence on the privacy and security of this information.

Organizations can monitor access and changes made to PII (personally identifiable information) and other confidential documents using the Wazuh FIM module.

You can find more information on how Wazuh helps organizations meet the HIPAA framework.

The image below shows the creation and deletion of a file on a monitored endpoint.

NIST 800-53

The National Institute of Standards and Technology (NIST) 800-53 is known as Security and Privacy Controls for Federal Information Systems and Organizations. It is a crucial component of the larger NIST Special Publication 800 series.

NIST 800-53 offers recommendations for managing information security and privacy for federal organizations and agencies. It helps organizations safeguard sensitive data while protecting their information systems and data from various threats.

You can view the vulnerability detection module results on the Wazuh dashboard which includes vulnerable applications and packages on the monitored endpoint. You can find more information on how Wazuh helps organizations meet the NIST 800-53 standard.

TSC

The Trust Services Criteria were developed by the Assurance Services Executive Committee (ASEC) of the AICPA. The TSC has five trust service areas which are security, availability, processing integrity, confidentiality, and privacy. Organizations implement TSC to protect customer data from unauthorized access, use, disclosure, modification or destruction.

Wazuh provides out-of-the-box tags for TSC Common Criterias that give organizations a standardized way to evaluate and report on the effectiveness of their information security policies. You can find more information on how Wazuh helps organizations meet TSC compliance.

The image below shows some of the Common criteria Wazuh helps organizations meet CC7.2 - Requiring ongoing monitoring for all irregular activity indicative of incidents.

System inventory

An up-to-date system inventory helps organizations optimize asset visibility in their environment, and is essential for maintaining good IT hygiene. hardware and operating system information, user accounts, installed packages, running processes and services, network ports, users, groups, and browser extensions. Wazuh agents use the Wazuh Syscollector module to collect inventory data from monitored endpoints and send them to the Wazuh server. All data is aggregated into dedicated indices in the Wazuh indexer and accessible through the Wazuh dashboard, enabling rapid detection and remediation without endpoint-by-endpoint inspection.

Navigate to Security operations > IT Hygiene to generate system inventory reports from the Wazuh IT hygiene module on the Wazuh dashboard.

You can also generate property-specific reports for a monitored endpoint. For example, you can get a report containing the list of installed software or a list of running processes on a monitored endpoint.

The inventory data collected can be queried using the Wazuh server API or Wazuh indexer API, which retrieves nested data in JSON format. For example, you can query the package inventory to check for the wazuh-agent package on a monitored endpoint using the Wazuh > Tools > API Console module on the Wazuh dashboard. Command line tools like cURL can also be used to query the inventory database.

Security Configuration Assessment

One of the objectives of implementing good IT hygiene is to reduce the attack surface of your organization. The Wazuh SCA module periodically scans monitored endpoints against policies based on the Center for Internet Security (CIS) benchmarks to identify security misconfigurations and flaws. The CIS benchmarks are essential guidelines for establishing a secure baseline configuration for critical assets. This minimizes vulnerabilities resulting from misconfigurations and reduces the risk of security breaches.

The Configuration Assessment module on the Wazuh dashboard provides each agent's SCA scan result. The results show the number of checks performed on the endpoint, how many failed, and the number of checks that passed. It also shows a score calculated based on the number of tests passed, giving you an overview of the level of compliance.

You can gain more insights from the Wazuh dashboard to view the passed and failed checks. Also, you can generate a CSV report to aid remediation activities, thereby improving the endpoint security posture.

You can see information such as rationale, remediation steps, and description of the checks performed on the endpoint on the Wazuh dashboard. This information is included in the report generated by Wazuh.

The SCA scan result above indicates a failure because the endpoint allows you to mount the cramfs file system. You can implement the remediation suggested in the report to improve the security posture.

Vulnerability management

The Wazuh vulnerability detection module identifies vulnerable applications by using vulnerability information available in our Wazuh CTI. Links to specific vulnerabilities on our Wazuh CTI are also available on each vulnerability ID.

You can download a report that contains security events related to discovered and resolved vulnerabilities on a monitored endpoint from the Wazuh dashboard. This feature allows you to identify endpoints with unresolved vulnerabilities and keep track of remediation activities.

The Wazuh vulnerability detection module also enables you to track remediation activities, which could serve as a progress report on improving or maintaining IT hygiene. For example, when a vulnerability is remediated, an alert is generated on the Wazuh dashboard. This feature detects when a patch or software upgrade resolves a previously detected vulnerability.

Malware detection

Malware detection is essential for safeguarding computer systems and networks from cyber threats. Organizations can improve their IT hygiene by identifying and mitigating malicious software that can cause data breaches, system compromises, and financial losses.

Wazuh offers an out-of-the-box ruleset designed to recognize malware patterns and trigger alerts for quick response. Wazuh also allows security analysts to create custom rules tailored to their environment, thereby optimizing their malware detection efforts. For example, we created custom rules to detect Vidar infostealer malware using Wazuh.

<group name="windows,sysmon,vidar_detection_rule,">
<!-- Vidar downloads malicious DLL files on victim endpoint -->
  <rule id="100084" level="10">
    <if_sid>61613</if_sid>
    <field name="win.eventdata.image" type="pcre2">(?i)\\\\.+(exe|dll|bat|msi)</field>
    <field name="win.eventdata.targetFilename" type="pcre2">(?i)\\\\ProgramData\\\\(freebl3|mozglue|msvcp140|nss3|softokn3|vcruntime140)\.dll</field>
    <description>Possible Vidar malware detected. $(win.eventdata.targetFilename) was downloaded on $(win.system.computer)</description>
    <mitre>
      <id>T1056.001</id>
    </mitre>
  </rule>
<!-- Vidar loads malicious DLL files -->
  <rule id="100085" level="12">
    <if_sid>61609</if_sid>
    <field name="win.eventdata.image" type="pcre2">(?i)\\\\.+(exe|dll|bat|msi)</field>
    <field name="win.eventdata.imageLoaded" type="pcre2">(?i)\\\\programdata\\\\(freebl3|mozglue|msvcp140|nss3|softokn3|vcruntime140)\.dll</field>
    <description>Possible Vidar malware detected. Malicious $(win.eventdata.imageLoaded) file loaded by $(win.eventdata.image)</description>
    <mitre>
      <id>T1574.002</id>
    </mitre>
  </rule>
<!-- Vidar deletes itself or a malicious process it creates -->
  <rule id="100086" level="7" frequency="5" timeframe="360">
    <if_sid>61603</if_sid>
    <if_matched_sid>100085</if_matched_sid>
    <field name="win.eventdata.image" type="pcre2">(?i)\\\\cmd.exe</field>
    <match type="pcre2">cmd.exe\\" /c timeout /t \d{1,}.+del /f /q \\".+(exe|dll|bat|msi)</match>
    <description>Possible Vidar malware detected. Malware deletes $(win.eventdata.parentCommandLine)</description>
    <mitre>
      <id>T1070.004</id>
    </mitre>
  </rule>
</group>

The rules above detect specific behaviors of the Vidar infostealer malware and trigger alerts on the dashboard.

Wazuh boosts its malware detection capabilities by integrating with threat intelligence sources such as VirusTotal, MISP, and more. Wazuh also offers support for integrating third-party malware detection tools such as ClamAV and Windows Defender. By collecting and analyzing logs from third-party malware detection tools, Wazuh provides security analysts with a centralized monitoring platform. Wazuh increases the efficiency in detecting malware by combining diverse threat intelligence from third-party tools, thereby improving the organization's IT hygiene.

The image below shows an alert of an event from VirusTotal processed by the Wazuh server.

Wazuh uses CDB lists (constant databases) containing indicators of compromise (IOCs) to detect malware. These lists contain known malware IOCs such as file hashes, IP addresses, and domain names. Wazuh proactively identifies malicious files by comparing the identified IOCs with the information stored in the CDB lists.

Regulatory compliance

Regulatory standards provide a global benchmark for best business practices to help improve customer trust and business reputation. Compliance with regulatory standards also helps organizations to enhance their IT hygiene.

Wazuh streamlines the process of meeting regulatory compliance obligations by offering a solution that addresses requirements of industry standards such as PCI DSS, HIPAA, GDPR, and others.

Wazuh uses its capabilities such as the SCA, vulnerability detection, FIM, and more to identify and report compliance violations. It also provides dedicated compliance dashboards to help monitor compliance status, identify improvement areas, and take appropriate remediation actions.

For example, you can get a general overview of the PCI DSS requirement of a monitored endpoint on the Wazuh dashboard.

You can drill down to the individual PCI DSS requirement from the Controls tab to discover where the policy violations occurred.

The image below shows alerts generated for vulnerabilities that violate the PCI DSS Requirement 11.2.1.

This feature is also available for other compliance standards such as GDPR, TSC, HIPAA, and NIST-800-53.

Wazuh for container security

Wazuh integrates with container platforms like Docker and Kubernetes and actively monitors container runtime events, application logs, and overall container health. Wazuh identifies anomalies by evaluating container logs against predefined rules. Additionally, it maintains a record of container engine actions to detect unauthorized activities in a containerized environment. It also monitors health metrics to prevent performance bottlenecks in an organization.

Wazuh container security features comprise monitoring container runtimes, tracking containerized application logs, monitoring container resource utilization, centralized logging, and container alert notifications. This comprehensive set of capabilities enhances security and streamlines incident response.

Container runtime monitoring

Organizations can enhance the security of their containerized applications by monitoring container events. They can proactively address unexpected behavior by promptly responding to alerts triggered by predefined rules. Wazuh also provides insight into container engine interactions and detects irregularities in containerized applications.

Monitoring the container engine

Wazuh captures real-time events performed by the Docker engine via its Docker listener module. This ensures that no crucial Docker event or operation goes undetected.

Monitoring user interaction with Docker resources demonstrates how Wazuh enhances visibility into the interactions of the container engine with the containers and the images.

Wazuh also monitors the creation and destruction of resources in Kubernetes clusters to help identify unauthorized actions and potential security breaches.

The blog post on Auditing Kubernetes with Wazuh demonstrates how to monitor Kubernetes resource interactions with Wazuh.

Monitoring containerized application logs

Wazuh allows organizations to monitor containerized applications. It provides visibility into the applications that are resident in the container. When the application events are forwarded to the Wazuh manager, Security engineers can create custom rules that align with the unique requirements of their organization. This facilitates a highly personalized approach that improves overall visibility into the containers and the applications they host.

The Monitoring container runtime documentation has more information about monitoring containerized application logs.

Monitor container resource utilization with Wazuh

Wazuh tracks and analyzes the resource consumption of containerized applications. It provides insights into the CPU, memory, and network usage statistics of containers, assisting in identifying performance bottlenecks.

Wazuh provides customizable alerts and notifications, enabling organizations to detect and proactively respond to unusual resource spikes or consumption patterns.

The blog post on Docker container security monitoring with Wazuh demonstrates how Wazuh monitors network utilization in a containerized environment.

Centralized logging and visualization of containers event

Wazuh centralizes container event logging and visualization. Its scalable indexer aggregates logs into a powerful search and analytics engine, providing real-time insights. This indexer handles event influx while also supporting compliance needs such as log retention policies.

Wazuh enables organizations to view container logs from a customized dashboard. Security professionals can track and analyze unfolding activities, swiftly identifying threats and unauthorized actions. This early detection enables security professionals to respond to security incidents as they arise swiftly, establishing an active approach to minimizing risks.

The image below displays the customized container dashboard of Wazuh, where events from all containers are showcased.

Container alert notification with Wazuh

Wazuh integrates with messaging platforms like email and Slack. It also integrates with case management solutions, like Jira , for incident response and real-time alerting. This ensures that security teams are promptly notified whenever potential threats or unauthorized actions occur in containerized environments.

The documentation on External API integration explains how the Integrator daemon allows Wazuh to connect to external APIs and case management systems tools like PagerDuty.

Google Cloud Platform

Wazuh connects with GCP through the Google Cloud publisher and subscriber services, also known as GCP Pub/Sub. These messaging services facilitate the transmission of log data from a GCP workload to a Wazuh instance. The image below shows the integration between GCP and Wazuh.

You can configure your Wazuh instance to receive GCP logs using the Pub/Sub service. Once configured, you can go to the Google Cloud module in the Wazuh dashboard to view logs related to your GCP services. We provide detailed guidelines on configuring Wazuh to receive GCP logs using the Pub/Sub service in our using Wazuh to monitor GCP services documentation.

The image below shows an example log received from a monitored GCP instance on the Wazuh dashboard.

Amazon Web Services

Wazuh provides CSPM to your AWS workloads by monitoring the AWS services and instances. Monitoring your AWS services includes collecting and analyzing log data about your AWS infrastructure using the Wazuh module for AWS.

You can use the Amazon Web Services module in the Wazuh dashboard to view logs related to AWS services.

Follow the AWS prerequisite documentation to set up your Wazuh instance for AWS log collection. The documentation shows a list of the supported AWS services that Wazuh can monitor. The image below shows an Amazon Security Hub log received using the CloudWatch service.

This control is designed to assess the security configuration of S3 buckets by verifying that user permissions are not granted through access control lists (ACLs). It is recommended to use AWS Identity and Access Management (IAM) policies rather than S3 bucket ACLs for managing user permissions.

Microsoft Azure

Wazuh integrates with Azure using the Log Analytics Workspace. The Azure Log Analytics workspace is a service that facilitates storing log data from Azure Monitor and other Azure services, such as Microsoft Defender for Cloud. Wazuh provides a native integration module for Azure that retrieves logs from the Log Analytics Workspace.

We provide detailed guidelines on configuring Wazuh to receive Azure Cloud logs using the Log Analytics Workspace in our Azure Log Analytics documentation. Once configured, you can set up your Wazuh deployment to retrieve Recommendations, Security alerts, and Regulatory compliance logs for your Azure cloud infrastructure.

The image below shows Azure security posture management logs received on Wazuh.

Cloud log data analysis and retention

Cloud environments generate large amounts of log data, vital for identifying security incidents. The Wazuh rules and decoders are responsible for parsing and analyzing log data to detect anomalous events. Wazuh collects and analyzes log data from various cloud platforms and services, such as AWS, Azure, Google Cloud, Office 365, and GitHub.

The image below is an example of an AWS dashboard on Wazuh showing the trend of events collected from the cloud infrastructure.

Wazuh monitors and logs activities in the cloud, providing a centralized view of user actions across the entire cloud infrastructure. Wazuh has out-of-the-box rules to detect suspicious or unauthorized activities. In addition to the in-built rules, users can create custom rules to consolidate threat detection.

Protect cloud-native applications

Wazuh provides protection for cloud-native applications, safeguarding them against security threats and vulnerabilities. It integrates with container orchestration platforms like Kubernetes and Docker, allowing it to monitor and analyze container activity in real time. Wazuh detects suspicious container behavior, unauthorized image changes, and potential security misconfigurations, ensuring the overall integrity of containerized applications.

The image below shows alerts generated from a monitored Docker infrastructure.

Some additional use cases for using Wazuh to monitor cloud-native applications are:

• Auditing Kubernetes with Wazuh

• Monitoring GKE audit logs

• Monitoring user interaction with Docker resources

• Monitoring container runtime

Furthermore, the Wazuh integration with cloud service providers enables monitoring and analysis of cloud-native application logs, ensuring comprehensive visibility into the environment and facilitating effective security operations.

Promote security operations in the cloud

Wazuh promotes security operations within cloud environments by allowing security teams to detect and respond to threats, mitigating damages, and reducing the overall impact on the cloud infrastructure. Furthermore, Wazuh facilitates red and blue team activities. The platform's customizable rules enable organizations to simulate attacks and test their security defenses. Blue teams can use the insights gained on Wazuh from red team activities to fine-tune their security measures and strengthen their defenses. The following resources demonstrate how to use the Stratus Red Team tool to simulate attacks on some cloud platforms and how to detect them with Wazuh:

• Adversary emulation on AWS with Stratus Red Team and Wazuh

• Adversary emulation on GCP with Stratus Red Team and Wazuh

The centralized logging and reporting capabilities of Wazuh simplify compliance management within cloud environments. It helps organizations meet regulatory requirements by capturing and storing audit trails, ensuring accountability, and facilitating the investigation of security incidents. Refer to the Wazuh dashboard documentation for more information about how Wazuh aids analysis, reporting, and compliance efforts.