Wazuh Brute Force Detection Guide

Credential-based attacks remain one of the most common techniques used by attackers to gain unauthorized access to systems, applications, and networks. Rather than exploiting software vulnerabilities, brute force attacks rely on repeatedly guessing usernames and passwords until valid credentials are discovered.

Weak passwords, reused credentials, and exposed login services make these attacks a persistent threat for organizations of every size.

Wazuh helps security teams identify brute force attacks by continuously monitoring authentication logs from endpoints, servers, firewalls, VPNs, and cloud workloads.

It analyzes failed login attempts in real time, correlates repeated authentication failures, and generates alerts when attack patterns match predefined or custom detection rules.

Combined with Active Response, Wazuh can automatically block malicious IP addresses before attackers successfully compromise an account.

According to the Verizon Data Breach Investigations Report (DBIR), stolen credentials and brute force techniques continue to play a significant role in security breaches, highlighting the importance of monitoring authentication activity across every environment.

In this guide, you’ll learn how Wazuh detects brute force attacks, what authentication sources it can monitor, how detection rules work, and how to strengthen your defenses with custom rules and automated responses.

What Is Wazuh Brute Force Detection?

Wazuh brute force detection is the process of identifying repeated failed authentication attempts across monitored systems and generating security alerts when those attempts indicate an automated password guessing attack.

Rather than simply recording failed logins, Wazuh correlates authentication events over time to distinguish between normal user mistakes and malicious behavior.

Organizations commonly use brute force detection to identify attackers attempting to compromise:

SSH servers
Windows Remote Desktop (RDP)
VPN gateways
Active Directory
Linux login services
Web applications
FTP servers
Email servers

Because Wazuh collects logs from multiple operating systems and applications, it can detect attacks against diverse authentication mechanisms using a unified rule engine.

Definition of Brute Force Attacks

A brute force attack is a credential attack in which an attacker repeatedly attempts different passwords, or combinations of usernames and passwords, until successful authentication occurs.

Common variations include:

Traditional brute force attacks
Dictionary attacks
Password spraying
Credential stuffing
Hybrid password attacks

Unlike password spraying, which tests one password against many accounts, traditional brute force attacks usually target a single account with numerous password guesses.

The MITRE ATT&CK framework classifies password guessing techniques under Valid Accounts and credential access tactics, documenting how attackers leverage repeated authentication attempts during intrusions.

Why Brute Force Detection Is Important

Successful brute force attacks can provide attackers with legitimate user credentials, allowing them to bypass many traditional security controls.

Early detection helps organizations:

Prevent unauthorized access
Reduce ransomware risk
Stop lateral movement
Detect compromised user accounts
Protect privileged administrator accounts
Meet compliance requirements for authentication monitoring

Without continuous monitoring, repeated login failures may go unnoticed until an attacker eventually discovers valid credentials.

How Wazuh Identifies Repeated Authentication Failures

Wazuh continuously monitors authentication logs generated by operating systems and applications.

Its detection pipeline generally follows these steps:

The Wazuh agent or log collector captures authentication events.
Decoders extract fields such as username, source IP address, hostname, authentication result, and timestamp.
Detection rules correlate multiple failed login events occurring within a configurable timeframe.
When thresholds are exceeded, Wazuh creates an alert with an appropriate severity level.
Optional Active Response actions can automatically block the attacking source.

The correlation engine allows Wazuh to recognize attack patterns instead of treating each failed login as an isolated event.

If you’re unfamiliar with how logs are parsed before rules execute, see How to Use Wazuh Logtest and Wazuh Decoder Guide.

Common Attack Vectors Wazuh Can Monitor

Wazuh supports brute force detection across numerous authentication services, including:

OpenSSH authentication logs
Windows Security Event Logs
PAM authentication events
FTP server logs
Web server authentication logs
VPN authentication logs
Email server login attempts
Active Directory authentication events
Cloud authentication services that forward logs into Wazuh

Because Wazuh normalizes events from different sources, analysts can monitor authentication activity across their entire infrastructure using a centralized dashboard.

How Wazuh Detects Brute Force Attacks

Brute force detection in Wazuh relies on several components working together.

Authentication events are first collected from monitored systems, then parsed into structured fields, correlated against detection rules, and finally converted into actionable alerts.

Organizations can also configure automated responses that immediately mitigate ongoing attacks.

Log Collection from Monitored Systems

Everything begins with authentication logs.

Depending on the platform, Wazuh collects logs from sources such as:

Linux authentication logs (/var/log/auth.log or /var/log/secure)
Windows Security Event Logs
SSH daemon logs
VPN appliances
FTP servers
Web servers
Email servers
Identity providers
Syslog servers

The Wazuh agent forwards these events to the Wazuh manager, where they become available for analysis.

If you need to configure centralized log collection first, see How to Configure Wazuh as a Centralized Syslog Server.

Decoders Parse Authentication Logs

Before rules can detect brute force activity, Wazuh decoders convert raw log entries into structured fields.

Typical extracted fields include:

Username
Source IP address
Destination host
Authentication status
Log source
Timestamp
Process name
Event ID

Structured data enables correlation rules to compare multiple authentication attempts accurately.

For organizations creating custom authentication detections, understanding decoders is essential. See Wazuh Decoder Guide.

Rules Correlate Repeated Failed Login Attempts

Once events are decoded, Wazuh applies its rules engine.

Rather than generating a high-severity alert for every failed login, correlation rules evaluate patterns such as:

Multiple failures from the same IP
Multiple failures targeting one account
Failures across several systems
Authentication attempts within short time windows
Failed logins followed by a successful login

This event correlation significantly reduces alert fatigue while improving detection accuracy.

Organizations frequently customize thresholds to match their authentication policies.

For more information on rule creation, see How to Create Custom Detection Rules in Wazuh (With Examples).

Alert Generation and Severity Levels

When correlation rules match a brute force pattern, Wazuh generates an alert containing information such as:

Source IP address
Username
Target system
Number of failed attempts
Detection rule ID
Severity level
Timestamp
Decoder information

Security analysts can investigate these alerts through the Wazuh Dashboard or forward them to external SIEM platforms.

The severity assigned depends on factors including the number of failures, affected accounts, and rule configuration.

Active Response Options

Detection alone is often insufficient during an active attack.

Wazuh Active Response allows organizations to automatically respond when brute force thresholds are exceeded.

Common automated actions include:

Blocking attacker IP addresses with firewall rules
Disabling compromised user accounts
Terminating malicious sessions
Executing custom response scripts
Triggering notifications through Slack, email, or ticketing platforms

Automated containment dramatically reduces the time attackers have to continue password guessing.

To learn more, see How to Configure Wazuh Active Response.

The Cybersecurity and Infrastructure Security Agency recommends implementing automated protections such as account lockout policies, multi-factor authentication, and continuous monitoring to reduce the effectiveness of password attacks.

Types of Brute Force Attacks Wazuh Can Detect

One of Wazuh’s strengths is its ability to monitor authentication activity across numerous operating systems, network services, and enterprise applications.

Whether attackers target Linux servers, Windows infrastructure, VPN appliances, or business applications, Wazuh can analyze authentication logs and detect suspicious login behavior.

SSH Brute Force Attacks

SSH servers are among the most frequently targeted internet-facing services.

Wazuh monitors:

Failed SSH logins
Invalid usernames
Root login attempts
Authentication failures from the same IP
Successful login after repeated failures

SSH monitoring is commonly used to identify internet-wide scanning and automated password attacks.

Windows RDP Login Attacks

Remote Desktop Protocol (RDP) is another common target for credential attacks.

Wazuh analyzes Windows Security Events to detect:

Failed Remote Desktop logins
Excessive authentication failures
Multiple account targeting
Suspicious login patterns
Geographic anomalies when combined with external enrichment

These detections are particularly valuable for exposed RDP servers.

Linux Local Authentication Attempts

Not every brute force attack originates over the network.

Wazuh also detects repeated failures involving:

Local console logins
sudo authentication
PAM authentication failures
Service account authentication
Administrative privilege escalation attempts

Monitoring local authentication helps identify insider threats and compromised endpoints.

FTP Authentication Attacks

Legacy FTP services remain attractive targets because they often rely solely on passwords.

Wazuh can detect:

Repeated FTP login failures
Anonymous login abuse
Invalid user enumeration
High-volume authentication attempts
Distributed attacks against FTP servers

Web Application Login Attacks

Many organizations expose web application login portals to the internet.

By monitoring web server and application logs, Wazuh can identify:

Failed web logins
Credential stuffing attempts
Password spraying
Repeated authentication failures
Suspicious login bursts from individual IP addresses

Custom decoders often improve visibility for proprietary applications.

VPN Authentication Failures

VPN gateways are frequent targets because successful authentication provides direct network access.

Wazuh monitors VPN platforms for:

Failed VPN logins
MFA failures
Repeated password attempts
Authentication lockouts
Successful login after numerous failures

These detections are especially valuable for remote work environments.

Email Server Authentication Attacks

Attackers frequently target email accounts because they often enable password resets for other services.

Wazuh can monitor authentication logs from supported mail platforms to detect:

IMAP login failures
SMTP authentication abuse
POP3 authentication attempts
Repeated password guessing
Account lockouts

Active Directory Authentication Failures

In enterprise Windows environments, Active Directory is often the primary authentication service.

Wazuh can analyze domain authentication events to identify:

Domain account lockouts
Kerberos authentication failures
NTLM authentication failures
Password spraying campaigns
Privileged account targeting
Repeated failed domain logins

Monitoring Active Directory authentication provides early visibility into attacks that may precede privilege escalation or lateral movement across the network.

Wazuh Components Involved in Brute Force Detection

Several Wazuh components work together to detect brute force attacks.

Authentication logs must first be collected, parsed into structured data, correlated using detection rules, indexed for fast searching, and displayed to security analysts.

Understanding the role of each component makes it easier to troubleshoot detection issues and customize your deployment.

Log Collectors

Log collection is the first step in the detection pipeline.

The Wazuh agent (or remote syslog sources) gathers authentication events from monitored systems and forwards them to the Wazuh manager for processing.

Common log sources include:

Linux authentication logs (/var/log/auth.log or /var/log/secure)
Windows Security Event Logs
SSH daemon logs
Apache and Nginx authentication logs
FTP server logs
VPN gateway logs
Mail server authentication logs
Active Directory authentication events

Without reliable log collection, brute force attacks cannot be detected because no authentication events reach the rules engine.

If you need to configure endpoint monitoring first, see How to Configure ossec.conf for Log Monitoring in Wazuh.

Decoders

Raw authentication logs come in many different formats.

Decoders normalize these logs by extracting structured fields such as:

Username
Source IP address
Destination host
Authentication result
Event ID
Timestamp
Process name
Service name

These parsed fields allow detection rules to compare related events instead of relying on raw log text.

For unsupported applications, administrators can build custom decoders to recognize proprietary authentication logs.

Related guides:

Detection Rules

After decoding, Wazuh evaluates each authentication event against its rules engine.

Rules determine whether an event represents:

A normal failed login
A suspicious authentication attempt
A confirmed brute force attack
A successful login following multiple failures

Rather than analyzing events independently, Wazuh can correlate repeated failures occurring within configurable time windows.

Administrators frequently customize:

Failure thresholds
Severity levels
Correlation logic
Rule inheritance
Rule exclusions

Custom rules are particularly useful for applications with unique authentication messages.

See How to Create Custom Detection Rules in Wazuh (With Examples) for detailed rule examples.

Active Response

Once a brute force attack is detected, Wazuh can automatically execute predefined response actions.

Common Active Response actions include:

Blocking attacker IP addresses
Updating firewall rules
Disabling compromised accounts
Killing malicious processes
Running custom scripts
Triggering external automation workflows

Automated responses reduce attacker dwell time and minimize the likelihood of credential compromise.

The Center for Internet Security recommends combining authentication monitoring with automated response capabilities to reduce the impact of credential-based attacks.

To learn more, see How to Configure Wazuh Active Response.

Wazuh Dashboard

The Wazuh Dashboard provides analysts with a centralized interface for investigating brute force alerts.

Analysts can:

Review authentication events
Filter by username or IP address
Examine alert timelines
Correlate related events
Identify targeted systems
Launch incident investigations

Dashboards also make it easier to identify long-running password attacks that may span multiple endpoints.

Wazuh Indexer

The Wazuh Indexer stores authentication events and generated alerts, enabling fast searches and historical analysis.

Its responsibilities include:

Indexing authentication logs
Storing correlated alerts
Supporting dashboard searches
Powering visualizations
Retaining historical attack data

Proper Indexer sizing becomes increasingly important in environments generating thousands of authentication events per minute.

Related resources:

Prerequisites

Before configuring brute force detection, verify that your Wazuh deployment is collecting authentication logs correctly and that all components are synchronized.

Most detection problems stem from missing log sources, improperly configured agents, or inconsistent timestamps rather than faulty detection rules.

Supported Wazuh Versions

Brute force detection is supported by modern Wazuh releases that include:

Built-in authentication decoders
Correlation rules
Active Response
Dashboard alerting
Indexer integration

For production deployments, always use a currently supported Wazuh version to benefit from updated detection rules, decoder improvements, and security patches.

Check the official Wazuh documentation for version-specific features and compatibility.

Agent Installation

Authentication events must reach the Wazuh manager before they can be analyzed.

Verify that:

Wazuh agents are installed
Agents are connected
Log collection is enabled
Authentication logs are included
Agent status is healthy

If agents are offline or disconnected, authentication events will never reach the rules engine.

Related guides:

Manager Configuration

The Wazuh manager should be configured to:

Receive agent events
Load authentication decoders
Enable detection rules
Process Active Response actions
Store generated alerts

If custom rules are being used, verify they load successfully without XML or syntax errors before testing.

Time Synchronization

Accurate timestamps are essential for event correlation.

Because brute force detection depends on identifying repeated failures within a defined time window, even small clock differences can prevent rules from triggering correctly.

Best practices include:

Synchronize endpoints using NTP
Synchronize Wazuh managers
Synchronize Indexer nodes
Verify consistent time zones
Monitor clock drift regularly

Time synchronization is especially important in clustered environments where authentication events originate from multiple systems.

Firewall and Network Considerations

Network connectivity should allow:

Agents to communicate with managers
Managers to communicate with the Indexer
Dashboard access
Active Response execution
Syslog forwarding (if applicable)

Verify that firewalls are not blocking authentication log forwarding or Active Response communications.

Required Log Sources

Brute force detection depends entirely on authentication logs.

Typical required sources include:

Platform	Common Log Source
Linux	`/var/log/auth.log`, `/var/log/secure`
Windows	Security Event Log
SSH	OpenSSH daemon logs
Apache	Access and authentication logs
Nginx	Access and authentication logs
VPN	VPN authentication logs
FTP	FTP server logs
Email	Mail authentication logs
Active Directory	Domain controller security events

The broader your authentication visibility, the more effective your brute force detection coverage will be.

Configuring Wazuh Brute Force Detection

Configuring brute force detection involves enabling authentication log collection, validating the built-in detection rules, creating custom rules where necessary, and tuning correlation settings to match your environment.

While Wazuh includes many authentication rules out of the box, every organization has unique login patterns that may require threshold adjustments.

Enable Authentication Log Monitoring

The first step is ensuring authentication events are being collected from every system that users authenticate against.

Without complete log coverage, attackers may exploit systems that are invisible to Wazuh.

Linux Authentication Logs

Linux systems typically record authentication events in:

/var/log/auth.log
/var/log/secure

Verify that:

Logcollector is monitoring the correct files.
SSH daemon logs are included.
PAM authentication events are captured.
Failed sudo attempts are logged.
Authentication failures appear in wazuh-logtest during testing.

If you’re monitoring SSH activity, see How to Monitor Failed SSH Login Attempts Using Wazuh.

Windows Event Logs

On Windows endpoints, enable collection of Security Event Logs that contain authentication events.

Common events include:

Successful logons
Failed logons
Account lockouts
Credential validation failures
Remote Desktop authentication events

Confirm that the Windows agent has permission to access the Security log and that relevant Event IDs are reaching the manager.

Web Server Authentication Logs

If users authenticate through web applications, configure Wazuh to monitor:

Apache authentication logs
Nginx authentication logs
Reverse proxy logs
Application authentication logs
API gateway logs

For proprietary applications, custom decoders and rules may be required.

Verify Built-in Detection Rules

Before writing custom rules, understand what Wazuh already detects.

The default ruleset contains numerous authentication and brute force detection rules that can often be reused or extended.

Testing built-in rules first prevents unnecessary customization.

Review Existing Authentication Rules

Inspect the authentication-related rules included with the default ruleset.

Review:

Rule IDs
Matching conditions
Parent-child relationships
Severity levels
Frequency settings

This helps identify whether a built-in rule already covers your use case.

Understand Rule Inheritance

Many authentication rules inherit conditions from parent rules.

Instead of duplicating logic, child rules extend existing detections by adding:

Frequency thresholds
Additional field matching
Severity adjustments
Environment-specific conditions

Understanding inheritance keeps custom rules smaller and easier to maintain.

For more information, see How to Map Complex Log Fields Using Wazuh Parent Child Rules.

Test Default Behavior

Before making changes:

Generate several failed logins.
Review the decoded output.
Confirm the expected rule fires.
Verify alert severity.
Check the Dashboard.
Confirm Indexer storage.

Testing establishes a baseline that makes later tuning much easier.

Create Custom Detection Rules

Organizations often need rules tailored to proprietary applications or internal authentication systems.

Custom rules can detect:

Internal application login failures
Cloud identity providers
Custom VPN appliances
Proprietary APIs
Legacy authentication systems

Always validate new rules with wazuh-logtest before deploying them.

Related guides:

Detect Organization-Specific Login Failures

Custom rules can identify authentication failures unique to your environment, including:

Internal application login errors
Custom API authentication failures
Third-party authentication gateways
SSO platform events
Business application login failures

Using application-specific fields often improves detection accuracy while reducing false positives.

Configure Thresholds

Thresholds determine when repeated authentication failures become suspicious.

Common tuning considerations include:

Number of failed attempts
Number of affected accounts
Source IP reputation
Authentication service
Business hours
Administrative accounts

Lower thresholds increase sensitivity but may also increase false positives.

Adjust Severity Levels

Different authentication failures deserve different alert priorities.

For example:

Single failed login → Low severity
Multiple failed logins → Medium severity
Password spraying → High severity
Successful login after repeated failures → Critical severity

Severity tuning helps analysts prioritize genuine attacks.

Configure Rule Frequency and Timeframe

Correlation settings define how Wazuh distinguishes normal user behavior from malicious credential attacks.

Proper tuning is essential for balancing detection accuracy with alert volume.

Frequency

Frequency specifies how many matching authentication events must occur before an alert is generated.

For example:

Five failed logins
Ten failed SSH attempts
Twenty VPN failures

The appropriate value depends on normal authentication behavior within your organization.

Timeframe

Timeframe defines the observation window during which matching events are counted.

Examples include:

Five failures within one minute
Ten failures within five minutes
Twenty failures within fifteen minutes

Shorter windows are better at detecting automated attacks, while longer windows can identify slow brute force attempts.

Ignore Periods

Ignore periods suppress repeated alerts after a rule has already fired.

Benefits include:

Reducing alert fatigue
Preventing duplicate incidents
Improving analyst efficiency
Limiting repeated notifications

Carefully chosen ignore periods help keep alert queues manageable without hiding ongoing attacks.

Correlation Settings

Advanced correlation can combine multiple authentication indicators, such as:

Username
Source IP address
Destination host
Authentication service
Geographic location
Authentication outcome

Combining these fields produces higher-confidence detections while minimizing false positives in busy enterprise environments.

Detecting SSH Brute Force Attacks

SSH is one of the most frequently targeted services exposed to the internet.

Automated bots continuously scan public IP addresses looking for SSH servers and attempt thousands of username and password combinations.

Wazuh can detect these attacks by monitoring SSH authentication logs, correlating repeated failures from the same source, and generating alerts before an attacker successfully authenticates.

SSH brute force detection is particularly valuable for Linux servers hosted in cloud environments, where internet-facing SSH services often receive constant attack traffic.

Monitor SSH Authentication Logs

The first step is ensuring Wazuh is collecting SSH authentication events.

Depending on your Linux distribution, SSH logs are typically stored in:

Distribution	Authentication Log
Ubuntu/Debian	`/var/log/auth.log`
RHEL/CentOS/Rocky	`/var/log/secure`
Amazon Linux	`/var/log/secure`
SUSE	`/var/log/messages` (depending on configuration)

Common SSH events include:

Failed password attempts
Invalid usernames
Successful logins
Root login attempts
Public key authentication failures
Session openings and closures

Verify these logs are included in your agent’s log monitoring configuration before testing detection rules.

Example SSH Attack Logs

A typical brute force attack generates many failed authentication entries within a short period.

Example:

Jul 15 14:33:21 server01 sshd[2458]: Failed password for invalid user admin from 203.0.113.25 port 51822 ssh2

Jul 15 14:33:24 server01 sshd[2459]: Failed password for invalid user admin from 203.0.113.25 port 51830 ssh2

Jul 15 14:33:27 server01 sshd[2460]: Failed password for invalid user admin from 203.0.113.25 port 51844 ssh2

Jul 15 14:33:30 server01 sshd[2461]: Failed password for invalid user admin from 203.0.113.25 port 51858 ssh2

Individually, these events may represent harmless login failures.

Correlated together, however, they strongly indicate an automated brute force attack.

Detection Rule Walkthrough

Wazuh’s detection engine processes SSH authentication events through several stages:

Logcollector reads the authentication log.
SSH decoders identify authentication fields.
Rules classify failed login events.
Correlation rules count repeated failures from the same source IP or username.
A brute force alert is generated once the configured threshold is exceeded.

Administrators can customize rules to trigger based on:

Source IP address
Username
Number of failures
Time window
Target host
Authentication method

Organizations often lower thresholds for privileged accounts such as root or service administrators.

If you plan to customize these detections, see How to Create Custom Detection Rules in Wazuh (With Examples).

Sample Wazuh Alert

A typical SSH brute force alert may contain information such as:

Rule ID: 5712
Level: 10

Description:
Multiple SSH authentication failures detected.

Source IP:
203.0.113.25

Username:
admin

Attempts:
15 failed logins

Host:
server01

Log Source:
/var/log/auth.log

Security analysts should review:

Whether the source IP has targeted other systems.
Whether successful authentication occurred afterward.
Whether additional attack techniques followed the login attempts.
Whether the username is a privileged account.

Recommended Response Actions

After detecting an SSH brute force attack, organizations should respond quickly to prevent credential compromise.

Recommended actions include:

Block the attacking IP address using Active Response.
Enable multi-factor authentication (where supported).
Disable password authentication in favor of SSH keys.
Review successful logins following the attack.
Lock compromised accounts if necessary.
Investigate whether the attacker targeted multiple servers.

The Open Worldwide Application Security Project recommends combining strong authentication controls, rate limiting, and account lockout mechanisms to reduce the effectiveness of automated credential attacks.

For automated mitigation, see How to Configure Wazuh Active Response.

Detecting Windows RDP Brute Force Attacks

Remote Desktop Protocol (RDP) is one of the most common targets for attackers seeking unauthorized access to Windows servers and workstations.

Internet-exposed RDP services are routinely scanned by automated bots attempting to guess user credentials.

Wazuh can detect these attacks by monitoring Windows Security Event Logs and correlating repeated failed authentication attempts.

Monitor Windows Security Events

Enable collection of Windows Security Event Logs through the Wazuh agent.

Important authentication events include:

Successful logons
Failed logons
Account lockouts
Credential validation failures
Network logons
Remote Desktop logons

Ensure that Security auditing is enabled through Windows Group Policy so authentication events are actually recorded.

Important Event IDs

Several Windows Event IDs are particularly useful when detecting RDP brute force attacks.

Event ID	Description
4624	Successful logon
4625	Failed logon
4648	Logon using explicit credentials
4771	Kerberos pre-authentication failure
4776	NTLM authentication attempt
4740	User account locked out

Repeated occurrences of Event ID 4625 from the same source are among the strongest indicators of an active brute force attack.

Microsoft documents these authentication events in its Windows Security Auditing reference.

Detection Configuration

Effective RDP detection typically correlates:

Multiple failed logons
Identical source IP addresses
Short time windows
Repeated targeting of privileged accounts
Successful logons following numerous failures

Organizations may also create separate thresholds for:

Domain administrators
Service accounts
Executive users
Remote administration systems

Proper tuning reduces false positives caused by users entering incorrect passwords.

Sample Alert

Example RDP brute force alert:

Rule ID: 6021
Level: 12

Description:
Possible Remote Desktop brute force attack detected.

Target Host:
WIN-SERVER01

Source IP:
198.51.100.42

Username:
Administrator

Authentication Failures:
27

Event ID:
4625

Analysts should determine whether the attacker later achieved a successful login or moved laterally within the environment.

Blocking Malicious IP Addresses

Once malicious RDP activity has been confirmed, Active Response can automatically initiate containment.

Common response actions include:

Add Windows Firewall rules.
Block IP addresses on perimeter firewalls.
Temporarily disable targeted accounts.
Notify administrators immediately.
Forward alerts to SIEM or SOAR platforms.
Trigger incident response workflows.

Automating these actions significantly reduces the attacker’s opportunity to compromise valid credentials.

Related guide: How to Configure Wazuh Active Response

Detecting Web Application Login Attacks

Many organizations expose authentication portals through web applications rather than directly through operating system services.

Attackers frequently target these portals using credential stuffing, password spraying, and traditional brute force attacks.

Wazuh can monitor web server logs, reverse proxies, and application-specific authentication events to detect suspicious login activity.

Apache Authentication Failures

Apache HTTP Server logs can reveal repeated authentication failures against protected resources.

Wazuh can detect patterns such as:

Repeated HTTP Basic Authentication failures
Failed login requests
Invalid usernames
Authentication bursts from one IP
Multiple failed requests targeting the same account

Related guide: How to Monitor Apache Logs with Wazuh

Nginx Authentication Failures

Nginx commonly acts as both a web server and reverse proxy.

Authentication-related events may include:

HTTP 401 responses
Failed Basic Authentication
Repeated POST requests to login endpoints
Authentication rate spikes
Reverse proxy authentication failures

Monitoring Nginx logs helps identify attacks before they reach backend applications.

Application Login Logs

Many applications maintain their own authentication logs separate from the web server.

Examples include:

CMS login attempts
Customer portal authentication
REST API authentication
Single Sign-On events
Identity provider logs
OAuth authentication failures

Organizations should configure Wazuh to monitor these application logs alongside Apache or Nginx access logs to obtain complete visibility into login activity.

Reverse Proxy Authentication Logs

Reverse proxies such as Nginx, Apache, and API gateways often authenticate users before forwarding requests to backend applications.

Useful indicators include:

Failed authentication requests
Invalid bearer tokens
Rejected API keys
Excessive login attempts
Authentication rate limiting events

Correlating reverse proxy logs with backend application logs provides higher-confidence detections while reducing false positives.

Custom Web Applications

Many organizations develop proprietary applications with unique authentication formats.

In these environments, administrators should:

Collect the application’s authentication logs.
Create custom decoders to extract usernames, IP addresses, and login results.
Build correlation rules for repeated failures.
Test rules using wazuh-logtest.
Tune thresholds based on normal user behavior.

Custom rules allow Wazuh to detect brute force attacks against virtually any application that generates authentication logs.

Related resources:

Using Active Response to Block Brute Force Attacks

Detecting a brute force attack is only part of the defense strategy.

To minimize the likelihood of a successful compromise, organizations should respond immediately after suspicious authentication activity is detected.

Wazuh’s Active Response framework allows administrators to automatically execute predefined actions whenever detection rules are triggered.

By combining real-time detection with automated containment, security teams can significantly reduce attacker dwell time and limit the effectiveness of password guessing attacks.

Related guide: How to Configure Wazuh Active Response

How Active Response Works

Active Response is Wazuh’s automated incident response mechanism.

When a detection rule meets its configured conditions, the Wazuh manager can execute one or more response actions either locally on an endpoint or remotely from the manager.

The typical workflow is:

Authentication logs are collected.
Decoders extract authentication fields.
Detection rules identify a brute force attack.
An alert is generated.
Active Response executes the configured action.
The response is logged for auditing purposes.

Response actions can be temporary or permanent depending on your configuration.

Automatically Blocking IP Addresses

The most common response to a brute force attack is blocking the attacker’s source IP address.

After a rule triggers, Wazuh can automatically:

Block the attacking IP
Drop future connections
Add firewall rules
Prevent additional authentication attempts
Remove temporary blocks after a configurable timeout

Temporary blocks are often preferred because they reduce the risk of permanently blocking legitimate users who accidentally trigger authentication thresholds.

Organizations should also maintain allowlists for trusted administrative IP addresses to prevent accidental lockouts.

Firewall Integration

Active Response integrates with several firewall technologies, allowing organizations to stop attacks before additional authentication attempts occur.

Common integrations include:

Linux iptables
Linux nftables
Windows Defender Firewall
pfSense
OPNsense
External firewall appliances through custom scripts

Organizations with layered security architectures may also forward Wazuh alerts to SOAR platforms that automate blocking across multiple security devices.

The National Institute of Standards and Technology recommends automated containment and centralized logging as part of an organization’s incident response capability.

Linux iptables/nftables Examples

Linux servers commonly use iptables or nftables to block malicious traffic.

Typical automated actions include:

Dropping packets from attacker IP addresses
Rejecting new SSH connections
Blocking repeated authentication attempts
Removing temporary firewall rules after expiration

For example, a response script may:

Add a DROP rule for the attacking IP.
Log the action.
Remove the rule after 10 or 30 minutes.

This approach limits disruption while slowing automated password guessing attacks.

If your environment uses newer Linux distributions, consider using nftables, as it has largely replaced iptables in modern systems.

Windows Firewall Options

Windows endpoints can also participate in Active Response.

Common automated actions include:

Blocking inbound traffic from malicious IP addresses
Blocking RDP connections
Restricting SMB access
Creating temporary Windows Firewall rules
Logging response actions in the Windows Event Log

These actions help contain attacks targeting Remote Desktop and other Windows authentication services.

Safe Deployment Practices

Although automated blocking is powerful, improper configuration can disrupt legitimate users.

Recommended best practices include:

Test Active Response in a non-production environment first.
Use temporary blocks instead of permanent bans.
Maintain allowlists for administrators and trusted systems.
Exclude monitoring systems and backup servers where appropriate.
Carefully tune authentication thresholds to reduce false positives.
Review blocked IP addresses regularly.
Log every automated response for auditing and troubleshooting.

Many organizations initially deploy Active Response in monitoring mode before enabling automatic blocking across production systems.

Testing Brute Force Detection

Testing verifies that your detection pipeline is functioning correctly before relying on it in production.

Authentication logs should be collected, decoded, correlated, and displayed exactly as expected.

Regular testing also confirms that future configuration changes or Wazuh upgrades do not inadvertently disable brute force detection.

Use wazuh-logtest

One of the easiest ways to validate authentication rules is with wazuh-logtest.

This utility allows you to:

Test authentication logs without waiting for live events.
Verify decoder selection.
Confirm which rules match.
Review extracted fields.
Validate custom detection rules.
Troubleshoot rule inheritance.

Running wazuh-logtest before deploying custom rules helps prevent configuration errors from reaching production.

Related guide: How to Use Wazuh Logtest

Simulate Failed Login Attempts

After validating rules with wazuh-logtest, perform controlled authentication failures against a test system.

Examples include:

Multiple failed SSH logins
Repeated RDP authentication failures
Invalid VPN credentials
Failed FTP logins
Web application login failures
Incorrect Active Directory passwords

Ensure testing occurs in an isolated environment to avoid triggering account lockout policies or disrupting production users.

Verify Alert Generation

Once authentication failures occur, verify that Wazuh generates the expected alerts.

Confirm that:

The correct rule fires.
Alert severity matches expectations.
Source IP addresses are extracted correctly.
Usernames are identified.
Authentication service is recognized.
Correlation thresholds function as expected.

If alerts fail to appear, review decoder output before modifying detection rules.

Validate Active Response

If automated responses are enabled, verify that they execute correctly.

Testing should confirm:

Firewall rules are created.
Malicious IP addresses are blocked.
Temporary blocks expire correctly.
Response scripts complete successfully.
Audit logs record every action.

Administrators should also verify that trusted users remain unaffected by the configured thresholds.

Review Dashboard Alerts

Finally, inspect the Wazuh Dashboard to ensure alerts are indexed and searchable.

Review:

Alert timestamps
Source IP addresses
Usernames
Rule IDs
Alert severity
Correlated events
Active Response actions

Confirm that dashboards, filters, and saved searches accurately display authentication activity.

If alerts are missing from the dashboard, see Troubleshooting wazuh-logtest: Why Alerts Are Missing from JSON Output and How to Fix Missing Statistics in Wazuh Dashboard.

Understanding Wazuh Brute Force Alerts

A Wazuh brute force alert contains much more than a simple notification that authentication has failed.

Each alert includes metadata that helps analysts determine who was targeted, where the attack originated, how severe the activity is, and whether additional investigation is necessary.

Learning how to interpret these fields enables faster triage and more effective incident response.

Rule IDs

Every Wazuh alert is associated with a unique rule ID.

The rule ID identifies:

Which detection rule fired
Whether it was a built-in or custom rule
Parent-child rule relationships
Associated MITRE ATT&CK mappings (where applicable)
Alert description

During investigations, analysts often search by rule ID to identify similar attacks across multiple systems.

Alert Levels

Each alert receives a severity level based on the configured detection rule.

Higher severity levels generally indicate:

More authentication failures
Greater confidence in malicious activity
Increased business impact
Stronger correlation evidence

Organizations frequently customize severity levels to reflect their own risk tolerance and incident response priorities.

Source IP

The source IP identifies where the authentication attempts originated.

Analysts should examine:

Internal vs. external origin
Known malicious IP reputation
Geographic location
Repeat offenders
Whether multiple systems were targeted

Repeated attacks from the same source may indicate automated scanning or botnet activity.

The SANS Institute recommends correlating authentication events with network indicators to distinguish isolated login failures from coordinated attacks.

Target Account

The target account identifies which user account was attacked.

Pay particular attention to:

Administrator accounts
Domain administrators
Service accounts
Shared administrative accounts
Privileged cloud identities

Repeated attacks against privileged accounts often warrant immediate investigation, even if authentication ultimately fails.

Authentication Method

The authentication method identifies which service or protocol generated the alert.

Examples include:

SSH
RDP
Kerberos
NTLM
FTP
VPN
HTTP Basic Authentication
Application-specific authentication

Understanding the authentication mechanism helps analysts determine the affected systems and appropriate remediation steps.

Timestamp

Accurate timestamps are essential when reconstructing attack timelines.

Analysts should compare authentication timestamps with:

Successful logins
Firewall events
Endpoint detections
VPN activity
Network connections
Privilege escalation events

Consistent time synchronization across endpoints ensures correlated events appear in the correct sequence.

Correlation Information

One of Wazuh’s most valuable features is event correlation.

Rather than displaying isolated login failures, correlated alerts often include:

Number of failed authentication attempts
Observation timeframe
Related usernames
Source IP address
Target host
Parent rule information
Triggering frequency
Previous matching events

This contextual information allows analysts to distinguish accidental password mistakes from genuine brute force attacks, improving both detection accuracy and incident response efficiency.

Reducing False Positives

While brute force detection is essential for identifying credential attacks, poorly tuned rules can generate excessive alerts.

High volumes of false positives can overwhelm security teams and make it harder to identify real attacks.

Effective tuning requires understanding normal authentication behavior within your environment and adjusting Wazuh rules to match expected activity.

Whitelist Trusted Systems

Some systems naturally generate repeated authentication attempts and may appear similar to brute force activity.

Examples include:

Vulnerability scanners
Identity management platforms
Backup systems
Monitoring tools
Automation servers
Configuration management systems

Trusted sources can be excluded from specific detection rules by using:

IP address exceptions
Host-based conditions
User-based exclusions
Custom rule logic

However, whitelisting should be used carefully.

Excessive exclusions can create blind spots that attackers may exploit.

Adjust Frequency Thresholds

Frequency settings determine how many failed authentication attempts trigger an alert.

For example:

Five failures within one minute may be appropriate for exposed SSH servers.
Twenty failures within ten minutes may be better for internal applications.
Higher thresholds may be needed for systems with many legitimate users.

Organizations should tune thresholds based on:

Number of users
Authentication volume
Internet exposure
Business requirements
Account lockout policies

A threshold that works for a small server may create unnecessary alerts in a large enterprise environment.

Tune Rule Conditions

Default Wazuh rules provide broad detection coverage, but organizations often need additional conditions to improve accuracy.

Common tuning approaches include:

Requiring failures from the same source IP.
Matching specific authentication services.
Monitoring only privileged accounts.
Adding username conditions.
Excluding known automation patterns.

For example, a rule detecting repeated SSH failures may become more accurate when combined with:

More than 10 failures.
Same source IP.
Invalid username attempts.
Short timeframe.

Customizing rule logic helps reduce unnecessary alerts while maintaining detection capability.

Exclude Service Accounts

Service accounts frequently authenticate automatically between systems.

Examples include:

Database connections
Application integrations
Scheduled scripts
Backup agents
API authentication

A misconfigured service account can generate hundreds of failed authentication events that resemble brute force activity.

Recommended practices include:

Identify service accounts generating failures.
Separate service account monitoring from user authentication monitoring.
Alert on unusual service account behavior rather than ignoring failures completely.
Avoid broadly excluding all automated accounts.

Unexpected service account authentication failures may indicate credential expiration, configuration issues, or compromise.

Handle Scheduled Authentication Failures

Scheduled tasks can create predictable authentication failures.

Examples include:

Expired passwords in automated jobs.
Old credentials stored in scripts.
Failed synchronization tasks.
Legacy applications using outdated passwords.

To handle these cases:

Identify recurring authentication patterns.
Compare failures against known maintenance windows.
Create targeted exclusions where appropriate.
Investigate unexpected schedule changes.

A scheduled failure pattern should be documented rather than permanently ignored.

Monitor Privileged Accounts Separately

Administrator accounts require stricter monitoring because attackers frequently target them during credential attacks.

Consider creating separate detection policies for:

Domain administrators
Root accounts
Cloud administrators
Database administrators
Security team accounts

Privileged account monitoring may use:

Lower failure thresholds.
Higher alert severity.
Immediate notifications.
Automatic response actions.

A small number of failed attempts against a privileged account may represent a greater risk than hundreds of failures against a standard user.

Monitoring Brute Force Activity in the Wazuh Dashboard

The Wazuh Dashboard provides security teams with centralized visibility into authentication activity, allowing analysts to identify brute force attempts, investigate affected systems, and track attack patterns over time.

Effective dashboard monitoring helps organizations move from reactive alert handling to proactive threat detection.

Authentication Alert Dashboards

Security teams can create dashboards focused specifically on authentication threats.

Useful dashboard widgets include:

Failed authentication events
Brute force alerts
Top attacking IP addresses
Targeted usernames
Most affected systems
Authentication failures over time
Active Response actions

These dashboards provide analysts with immediate visibility into credential-based attacks.

Filtering by Source IP

Source IP filtering is one of the fastest ways to investigate brute force activity.

Analysts can identify:

Repeated attacks from a single address.
Distributed attacks from multiple addresses.
Internal systems generating unusual failures.
Geographic attack patterns.

Useful investigation filters include:

Source IP address
Country or region
Username
Hostname
Authentication service
Rule ID

Filtering allows analysts to determine whether an event represents an isolated attack or part of a larger campaign.

Tracking Attack Trends

Long-term trend analysis helps organizations understand how brute force activity changes over time.

Security teams can monitor:

Daily authentication failures.
Increasing attack volumes.
Repeated targeting of specific systems.
Changes after security improvements.
Effectiveness of Active Response policies.

Trend monitoring can reveal:

New internet exposure.
Weak authentication controls.
Increased attacker activity.
Misconfigured applications.

Investigating Affected Users

When brute force alerts occur, analysts should investigate targeted accounts.

Review:

Username targeted.
Whether login succeeded afterward.
Account privileges.
Previous authentication activity.
Password reset events.
Related security alerts.

A successful login after repeated failures is often more suspicious than failed attempts alone because it may indicate compromised credentials.

Building Custom Visualizations

Organizations can create custom dashboard visualizations based on their security requirements.

Examples include:

Top brute force source IPs.
Failed login attempts by country.
Authentication failures by service.
Privileged account attacks.
Successful logins after failures.
Attack activity by time of day.

Custom visualizations allow security teams to focus on metrics that directly support their incident response processes.

For larger deployments, see The Ultimate Wazuh Indexer Guide for optimizing search and storage performance.

Best Practices for Wazuh Brute Force Detection

Effective brute force detection requires more than enabling default rules.

Organizations should combine complete authentication visibility, accurate rule tuning, automated response, and continuous monitoring to maintain strong protection against credential attacks.

Monitor All Authentication Sources

Attackers do not limit themselves to a single login method.

Organizations should monitor:

SSH
RDP
VPN
Web applications
Active Directory
FTP
Email services
Cloud authentication platforms
Internal applications

Complete authentication visibility improves the chance of detecting attacks early.

Use Multi-Layer Detection

No single detection method catches every brute force technique.

Combine:

Failed login monitoring.
Account lockout events.
Threat intelligence enrichment.
User behavior analysis.
Network monitoring.
Endpoint detection.

Layered detection improves coverage against:

Password spraying.
Credential stuffing.
Distributed brute force attacks.
Slow password guessing campaigns.

Correlate Failed and Successful Logins

A successful authentication after many failed attempts is a critical indicator.

Wazuh rules should correlate:

Failed login attempts.
Successful authentication.
Same username.
Same source IP.
Same host.

This helps identify cases where attackers eventually discover valid credentials.

Enable Active Response Carefully

Active Response can stop attacks quickly, but aggressive blocking can impact legitimate users.

Before enabling automatic blocking:

Test response actions.
Configure exceptions.
Use temporary blocks.
Monitor false positives.
Document response procedures.

Gradual deployment reduces operational risk.

Regularly Tune Detection Rules

Authentication behavior changes over time.

Regular tuning should review:

Alert frequency.
False positives.
Missed detections.
Threshold effectiveness.
New authentication services.

Security teams should periodically review whether detection rules still match the organization’s environment.

Related guide: How to Reduce False Positives in Wazuh

Test Custom Rules After Updates

Wazuh updates may introduce changes to:

Default rules.
Decoders.
Alert formats.
Detection behavior.

After upgrades:

Test custom authentication rules.
Validate decoders.
Confirm expected alerts.
Review rule conflicts.

Use wazuh-logtest to verify that custom detections continue working.

Related guide: How to Use Wazuh Logtest

Monitor Privileged Accounts Separately

Privileged accounts represent high-value targets.

Security teams should apply stricter monitoring to:

Root users.
Domain administrators.
Cloud administrators.
Database administrators.

Recommended controls include:

Lower alert thresholds.
Higher severity levels.
Immediate notifications.
Additional authentication requirements.

Integrate with Threat Intelligence

Threat intelligence enrichment improves brute force investigations.

Organizations can compare attacker IP addresses against:

Known malicious infrastructure.
Botnet sources.
Reputation databases.
Previous attack activity.

Wazuh can integrate with threat intelligence platforms to provide additional context during investigations.

Review Authentication Logs Regularly

Regular log review helps identify:

New attack patterns.
Misconfigured applications.
Weak authentication controls.
Repeated attack sources.

Security teams should establish review processes for:

High-severity alerts.
Privileged account failures.
Successful logins after failures.
Repeated external attacks.

Keep Systems Synchronized with NTP

Accurate timestamps are essential for authentication correlation.

All systems should synchronize time using Network Time Protocol (NTP), including:

Wazuh agents.
Wazuh managers.
Indexer nodes.
Domain controllers.
Authentication servers.

Proper time synchronization ensures that analysts can accurately reconstruct attack timelines and that correlation rules operate correctly.

For clustered deployments, see The Complete Wazuh Cluster Architecture Guide.

Common Brute Force Detection Issues and Troubleshooting

Although Wazuh provides built-in capabilities for detecting brute force attacks, detection failures can occur because of missing logs, incorrect configurations, rule conflicts, or incomplete integrations.

Troubleshooting should begin by verifying the entire detection pipeline:

Log collection → Decoding → Rule matching → Alert generation → Dashboard visibility → Automated response

Understanding where the failure occurs makes it easier to restore reliable brute force monitoring.

No Authentication Logs Collected

The most common reason brute force detection fails is that authentication logs never reach the Wazuh manager.

Possible causes include:

Wazuh agent is not installed or connected.
Authentication log monitoring is disabled.
Incorrect file paths are configured.
Syslog forwarding is misconfigured.
Permissions prevent log access.
The monitored service is writing logs elsewhere.

Troubleshooting steps:

Confirm the agent is connected.
Verify authentication logs exist on the endpoint.
Check the Wazuh agent configuration.
Restart the agent after configuration changes.
Confirm events appear on the manager.

Related guides:

Rules Not Triggering

When authentication logs are collected but alerts are not generated, the issue is usually related to decoding or rule matching.

Common causes include:

The decoder does not recognize the log format.
The wrong rule conditions are configured.
The frequency threshold is not reached.
The timeframe is too short.
The event does not contain required fields.

Troubleshooting steps:

Test logs using wazuh-logtest.
Verify the selected decoder.
Review matching rules.
Check rule inheritance.
Confirm correlation settings.

Related guides:

Too Many False Positives

High false positive rates often occur when detection thresholds are too aggressive or normal authentication behavior is not considered.

Common causes include:

Users frequently mistyping passwords.
Automated services using expired credentials.
Vulnerability scanners performing authentication checks.
Shared accounts generating repeated failures.

Solutions include:

Increasing failure thresholds.
Extending timeframes.
Adding trusted source exclusions.
Creating separate rules for service accounts.
Monitoring privileged users with stricter policies.

Related guide: How to Reduce False Positives in Wazuh

Active Response Not Blocking Attackers

If alerts are generated but attackers are not blocked, the issue may involve Active Response configuration.

Common causes include:

Active Response is disabled.
Response scripts are missing.
Firewall integration is incorrect.
Permissions prevent execution.
The rule is not configured for response actions.

Troubleshooting steps:

Verify Active Response configuration.
Confirm the rule triggers the response.
Review Active Response logs.
Test firewall commands manually.
Confirm the endpoint allows firewall modifications.

Related guide: How to Configure Wazuh Active Response

Windows Events Not Appearing

Windows brute force detection depends on collecting Security Event Logs.

Common issues include:

Security auditing is disabled.
The Wazuh agent lacks permissions.
Event channels are not configured.
Group Policy settings prevent auditing.
The wrong Event IDs are being monitored.

Verify collection of events such as:

4625 — Failed logon
4624 — Successful logon
4740 — Account lockout
4776 — Credential validation

SSH Logs Missing

SSH brute force detection requires access to SSH authentication logs.

Common causes of missing SSH events include:

Incorrect log file paths.
SSH logging level is insufficient.
The Wazuh agent is not monitoring authentication files.
The server uses a different authentication subsystem.

Troubleshooting steps:

Verify SSH logs exist.
Confirm sshd logging is enabled.
Check /var/log/auth.log or /var/log/secure.
Validate collection using wazuh-logtest.

Dashboard Alerts Missing

Sometimes brute force alerts are generated but do not appear in the Wazuh Dashboard.

Possible causes include:

Indexer connection problems.
Missing indices.
Dashboard synchronization issues.
Indexing failures.
Incorrect dashboard filters.

Troubleshooting steps:

Verify alerts exist on the manager.
Check Indexer health.
Confirm indices are available.
Review dashboard query filters.

Related guides:

Custom Rules Not Loading

Custom brute force rules may fail because of XML syntax errors, duplicate IDs, or incorrect rule placement.

Common problems include:

Invalid XML formatting.
Duplicate rule IDs.
Incorrect rule groups.
Missing decoder references.
Rule inheritance mistakes.

Recommended troubleshooting steps:

Validate XML syntax.
Test with wazuh-logtest.
Review manager logs.
Restart the Wazuh manager after changes.
Verify rule loading messages.

Related guides:

Real-World Example

Scenario

A security team manages a hybrid enterprise environment containing Linux servers, Windows infrastructure, VPN gateways, and a customer-facing web application.

Because many systems require remote authentication, the organization implements Wazuh to centralize authentication monitoring and detect credential-based attacks.

The environment includes:

Internet-facing Linux servers running SSH.
Windows servers providing Remote Desktop access.
VPN gateways used by remote employees.
A customer web application with custom authentication logs.

Attackers begin targeting the environment with multiple credential attacks:

Automated bots launch SSH brute force attempts against public Linux servers.
Another attacker performs password spraying against Windows RDP accounts.
Additional login attempts target the customer web application.

Detection Process

Wazuh agents collect authentication events from Linux and Windows systems, while syslog integrations forward VPN and application authentication logs.

The detection pipeline works as follows:

Linux SSH logs are collected from authentication files.
Windows Security Events are forwarded from domain systems.
VPN and application logs are ingested through centralized logging.
Wazuh decoders extract usernames, source IP addresses, and authentication results.
Built-in and custom rules correlate repeated failures.
High-severity brute force alerts are generated.

The security team uses custom rules to detect organization-specific authentication patterns while relying on built-in rules for standard SSH and Windows authentication events.

Related guides:

Automated Response

After multiple brute force thresholds are exceeded, Wazuh Active Response automatically blocks malicious IP addresses.

The response actions include:

Adding firewall blocks on Linux servers.
Blocking suspicious addresses on Windows Firewall.
Preventing additional SSH and RDP login attempts.
Recording response activity for investigation.

This reduces the attacker’s ability to continue password guessing while analysts investigate the incident.

Investigation and Improvement

Security analysts review the alerts in the Wazuh Dashboard and investigate:

Targeted usernames.
Attacker source addresses.
Authentication methods.
Failed login counts.
Whether successful authentication occurred.

The investigation confirms:

No successful compromises occurred.
Privileged accounts were targeted but protected.
Automated blocking prevented additional attempts.

After reviewing the attack, the team improves detection by:

Lowering thresholds for privileged accounts.
Adjusting correlation timeframes.
Adding new custom rules for application authentication.
Expanding threat intelligence enrichment.
Reviewing authentication visibility across the environment.

This example demonstrates how Wazuh combines log collection, detection rules, correlation, and automated response to protect hybrid environments from credential attacks.

Frequently Asked Questions (FAQ)

What is Wazuh brute force detection?

Wazuh brute force detection identifies repeated failed authentication attempts that indicate password guessing attacks.

It analyzes authentication logs, correlates repeated failures, and generates alerts when activity matches configured detection rules.

Question: Does Wazuh detect SSH brute force attacks?

Yes. Wazuh can detect SSH brute force attacks by monitoring Linux authentication logs, analyzing failed SSH login attempts, and correlating repeated failures from the same source.

Question: Can Wazuh detect Windows RDP brute force attacks?

Yes. Wazuh detects Windows RDP brute force attacks by analyzing Windows Security Event Logs, including failed authentication events such as Event ID 4625.

Question: How many failed logins trigger a Wazuh alert?

The number depends on the configured detection rule. Wazuh rules use frequency and timeframe settings to determine when repeated authentication failures become suspicious.

Organizations can customize these thresholds based on their environment.

Question: Can Wazuh automatically block brute force attackers?

Yes. Wazuh Active Response can automatically block malicious IP addresses using firewall integrations and custom response scripts.

Related guide: How to Configure Wazuh Active Response

Question: How do I reduce false positives?

Reduce false positives by:

Adjusting frequency thresholds.
Tuning rule conditions.
Excluding trusted systems.
Separating service accounts.
Monitoring privileged accounts independently.

Question: Can I create custom brute force detection rules?

Yes. Wazuh allows administrators to create custom rules for proprietary applications, authentication systems, and organization-specific attack patterns.

Question: How do I test brute force detection in Wazuh?

Use wazuh-logtest to validate decoders and rules, then simulate controlled authentication failures and verify alert generation in the Dashboard.

Related guide: How to Use Wazuh Logtest

Question: Which logs are required for brute force detection?

Required logs depend on the authentication source.

Common examples include:

Linux authentication logs.
Windows Security Events.
SSH logs.
VPN authentication logs.
Web application logs.
FTP authentication logs.
Active Directory events.

Question: Does Wazuh detect password spraying attacks?

Yes. Wazuh can detect password spraying attacks by correlating authentication failures across multiple accounts, usernames, and systems.

Custom rules may be required to identify organization-specific password spraying patterns.

Conclusion

Wazuh provides a powerful framework for detecting brute force attacks across diverse authentication sources, including SSH servers, Windows RDP environments, VPN gateways, web applications, and Active Directory systems.

By combining:

Comprehensive log collection.
Decoder-based event normalization.
Detection rule correlation.
Custom security rules.
Active Response automation.

Organizations can identify credential attacks quickly and reduce the likelihood of unauthorized access.

Effective brute force detection requires continuous improvement.

Security teams should regularly test detection logic, tune thresholds to minimize false positives, validate custom rules after updates, and review authentication activity to maintain strong visibility across their environments.

When properly configured, Wazuh helps organizations move from simply detecting failed login attempts to actively preventing credential-based attacks before they become security incidents.