Brute Force Attack: Definition, How It Works, and What to Do About It

A brute force attack is repeated password guessing (or key guessing) against a login or encrypted asset until something works. It’s one of the most common threats to authentication security, especially for internet-facing SSH, RDP, VPN, and SaaS logins. The good news: defenses like MFA, rate limiting, smart lockouts, and strong password hygiene stop most brute force attempts before they become account takeover.

How it works

Brute force is simple in concept: try credentials repeatedly, measure success/failure, and keep going. What makes it effective (and dangerous) is automation, scale, and attackers’ use of real-world password patterns.

Step-by-step flow (typical online brute force)

1. Target selection - Common targets: SSH, RDP, VPN portals, Microsoft 365/Google Workspace, web app login pages, API auth endpoints, and admin panels. - Attackers often scan for exposed services (e.g., SSH on 22, RDP on 3389) or enumerate login URLs.

2. Username strategy - Guess common usernames (admin, administrator, root, test) or harvest them from:

   • Public sources (company email patterns, LinkedIn, Git commits)
   • Leaked datasets
   • Error messages that reveal whether a username exists

3. Password strategy - Pure brute force: attempts every combination (rare online due to rate limits). - Dictionary attack: tries a wordlist of common passwords and variations. - Password spraying: tries a few common passwords across many accounts to avoid lockouts. - Credential stuffing: uses known leaked username/password pairs from other sites (often misclassified as “brute force,” but it’s distinct).

4. Automation and evasion - Tools send rapid authentication attempts and rotate:

   • Source IPs (botnets, proxies, cloud hosts)
   • User-agents, request headers, and timing (“low and slow”)
   • Attackers may aim for services with weak defenses: no MFA, no rate limiting, permissive lockout policies, or exposed admin accounts.

5. Success condition and post-auth actions - Once authenticated, attackers typically:

   • Establish persistence (new users/keys/tokens)
   • Enumerate assets and data
   • Move laterally (especially after RDP/SSH access)
   • Exfiltrate data or deploy ransomware

What brute force looks like across common services

• SSH brute force: repeated “Failed password” entries; attempts against root, service accounts, or newly created users.
• RDP brute force: many failed logons (often Event ID 4625) from external IPs; may correlate with exposed 3389/TCP.
• Web apps/SaaS: spikes in /login POST requests; failures for many users; sometimes “spray” patterns (same password attempted across many accounts).

Technical Notes: Indicators in logs (what to grep for)

Linux SSH (auth logs)

Common patterns include failed password attempts and invalid users:

# Debian/Ubuntu
sudo grep -E "Failed password|Invalid user|authentication failure" /var/log/auth.log | tail -n 50

# RHEL/CentOS/Rocky/Alma
sudo grep -E "Failed password|Invalid user|authentication failure" /var/log/secure | tail -n 50

Example log lines you may see:

Failed password for invalid user admin from 203.0.113.50 port 51122 ssh2
Failed password for root from 203.0.113.50 port 51123 ssh2

Quick count of top offending IPs:

sudo awk '/Failed password/ {print $(NF-3)}' /var/log/auth.log | sort | uniq -c | sort -nr | head

Windows RDP / Logon failures

On Windows, brute force commonly shows up as repeated failed logons:

• Security Event ID 4625 (An account failed to log on)
• Logon Type 10 (RemoteInteractive: often RDP)

PowerShell example to spot repeated failures:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} |
  Where-Object { $_.Message -match "Logon Type:\s+10" } |
  Select-Object -First 50 TimeCreated, Message

Web server / application logs

Look for high rates of login attempts and many 401/403 responses.

# NGINX access logs: find likely brute force against /login
sudo awk '$7 ~ /\/login/ {print $1, $4, $9, $7}' /var/log/nginx/access.log | tail -n 50

A strong signal is many distinct usernames failing from one IP (dictionary attack), or the same password pattern across many usernames (spray)—your app logs may capture the username field if you log it safely.

Why brute force works (even today)

• Password reuse and weak passwords are common.
• Internet-facing services are routinely scanned and attacked within minutes of exposure.
• Defenses are often inconsistent: some apps have MFA and rate limits; others don’t; legacy services may be exposed directly.

What to do next (practitioner actions)

If you suspect brute force activity, prioritize controls that reduce both likelihood and impact.

1) Turn on MFA everywhere you can

Enable MFA for admin accounts, VPN, email, and remote access. If you can, prefer phishing-resistant factors (like FIDO2/WebAuthn) for privileged accounts.

2) Rate limit and add adaptive challenges

Use per-IP and per-account throttling. Consider CAPTCHA only where it won’t harm legitimate users or accessibility.

3) Enforce lockouts carefully (avoid DoS)

Lockouts can stop brute force, but they can also let attackers lock out real users at will. In many cases, progressive delays (cooldowns) or risk-based controls are safer.

4) Block or restrict remote access exposure (especially RDP)

• Don’t expose RDP directly to the internet; require VPN/Zero Trust access.
• For SSH: disable password auth if feasible; use keys; restrict by IP.

If you’re securing endpoints in a business environment, pair these controls with strong endpoint protection and monitoring; see our comparison guide: best antivirus for windows business endpoints 2026.

5) Harden credentials with a password manager

Strong, unique passwords reduce brute force and credential-stuffing impact. A password manager makes that practical at scale.

If you need a business-ready option, 1Password is a common choice for teams (roles, sharing, admin controls): Try 1Password →.

6) Monitor for success, not only failures

Alert on: - A successful login immediately after many failures - New device sign-ins - New MFA enrollments - Privilege changes or creation of new admin accounts

7) Add perimeter protections where appropriate

• WAF rules for login endpoints
• Geo/IP allowlists where practical
• Fail2ban-style banning on servers

Technical Notes: Practical hardening snippets

SSH: disable password authentication (where feasible)

In /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no

Then reload SSH:

sudo systemctl reload sshd

Linux: auto-ban repeated failures with fail2ban (conceptual)

A common approach is to ban IPs after repeated failures (configure carefully to avoid blocking legitimate users):

sudo fail2ban-client status
sudo fail2ban-client status sshd

Web app: rate limiting (conceptual NGINX example)

Rate limiting login endpoints reduces high-speed guessing:

limit_req_zone $binary_remote_addr zone=loginlimit:10m rate=5r/m;

location = /login {
  limit_req zone=loginlimit burst=10 nodelay;
  proxy_pass http://app_backend;
}

When you’ll encounter it

You’re most likely to run into brute force attacks in these scenarios:

• After exposing a service to the internet
  Newly deployed servers with SSH or RDP open commonly see brute force attempts quickly, even without targeted attention.

• On common admin/login endpoints
  Web apps with /admin, /wp-login.php, /signin, /login, and similar routes are repeatedly probed and attacked.

• During credential-based incidents
  Following a public breach, attackers may shift to credential stuffing and password spraying against your organization’s email/VPN/SaaS—often reported internally as “brute force.”

• In logs as background noise
  Many organizations see constant low-level brute force attempts against exposed services. The key is determining when it’s escalating or successful.

Operationally, treat it as higher severity when: - Attempts are distributed (many IPs) indicating botnet/proxy use - You see targeted usernames (real employee accounts) rather than generic admin - There’s a successful login after repeated failures - Attempts coincide with password resets, MFA prompts, or new device sign-ins