How to Report Brute Force SSH and RDP Attacks: Log Evidence and Abuse Report Templates

If you run a server with SSH or RDP exposed to the internet, you already know the pattern: hundreds or thousands of failed login attempts per day from IP addresses you have never seen before. Automated bots cycle through common usernames and passwords around the clock, probing every reachable host. Most of these attempts fail, but the sheer volume means that weak credentials will eventually be found.

Reporting brute force attacks to the responsible ISP or hosting provider is one of the most effective ways to get compromised or malicious hosts shut down. In this guide, I walk through how to extract evidence from your logs, identify the abuse contact for the attacking IP, and file a report that leads to action. This is part of my complete IP abuse reporting guide, focused specifically on brute force login attacks.

How to Identify Brute Force Attacks

Brute force attacks leave unmistakable signatures in authentication logs. The key indicator is a high volume of failed login attempts from a single IP address (or a small cluster of IPs) over a short period.

SSH on Linux (auth.log / secure)

On Debian/Ubuntu systems, SSH authentication events are logged to /var/log/auth.log. On RHEL/CentOS/Fedora, check /var/log/secure. A typical brute force pattern looks like this:

Feb 14 03:21:07 web01 sshd[28401]: Failed password for invalid user admin from 203.0.113.47 port 52104 ssh2
Feb 14 03:21:09 web01 sshd[28403]: Failed password for invalid user root from 203.0.113.47 port 52108 ssh2
Feb 14 03:21:11 web01 sshd[28405]: Failed password for invalid user deploy from 203.0.113.47 port 52112 ssh2
Feb 14 03:21:13 web01 sshd[28407]: Failed password for invalid user ubuntu from 203.0.113.47 port 52116 ssh2
Feb 14 03:21:15 web01 sshd[28409]: Failed password for invalid user test from 203.0.113.47 port 52120 ssh2
Feb 14 03:21:17 web01 sshd[28411]: Failed password for invalid user postgres from 203.0.113.47 port 52124 ssh2

Notice the pattern: rapid-fire attempts (every 2 seconds), cycling through common usernames, all from the same source IP. To count attempts from each IP:

grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

This gives you a ranked list of attacking IPs by attempt count. Anything above 50-100 attempts is clearly automated.

RDP on Windows (Event Viewer)

Windows logs RDP authentication failures as Event ID 4625 in the Security log. Successful logons are Event ID 4624. To filter for failed RDP attempts in PowerShell:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 100 |
  Select-Object TimeCreated,
    @{N='IP';E={$_.Properties[19].Value}},
    @{N='User';E={$_.Properties[5].Value}},
    @{N='LogonType';E={$_.Properties[10].Value}} |
  Where-Object { $_.LogonType -eq 10 } |
  Format-Table -AutoSize

Logon Type 10 is "RemoteInteractive" — meaning RDP. A burst of 4625 events with Logon Type 10 from the same source IP is a brute force attack.

You can also count attempts per IP:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} |
  ForEach-Object { $_.Properties[19].Value } |
  Group-Object | Sort-Object Count -Descending | Select-Object -First 20

Fail2ban Logs

If you run fail2ban (and you should), it maintains its own log at /var/log/fail2ban.log and tracks bans:

2025-04-14 08:12:33,441 fail2ban.actions [1234]: NOTICE [sshd] Ban 203.0.113.47
2025-04-14 08:15:01,892 fail2ban.actions [1234]: NOTICE [sshd] Ban 198.51.100.22

To see all currently banned IPs:

fail2ban-client status sshd

Fail2ban logs are excellent supporting evidence because they show your automated defenses already flagged the IP as malicious.

Evidence Gathering Checklist

Before filing a report, assemble the following evidence. The more complete your report, the more likely the provider will act.

• Auth log excerpts — Include the raw log lines showing failed attempts. Include timestamps with timezone (UTC preferred).
• Attempt count per IP — Run the count commands above to show the scale of the attack.
• Fail2ban ban records — If applicable, include the ban log entries.
• Username patterns — List the usernames tried. Automated attacks typically cycle through root, admin, deploy, ubuntu, test, oracle, postgres, and other common service accounts.
• Time range — Specify the start and end timestamps of the attack.
• Your server's IP and hostname — The target of the attack (redact if you prefer, but include it for completeness).
• Geographic clustering — If multiple IPs are involved, note whether they share a common ASN or network block.

Save the raw log data as a text file. Providers prefer plain log excerpts over screenshots because they can verify timestamps and patterns.

Finding the Abuse Contact

Every IP address is registered to a network operator, and that operator is required to maintain an abuse contact. Here is how I find it:

1. Look up the IP using the IP Location tool. Enter the attacking IP address and note the ISP, organization, and ASN.
2. Check the WHOIS record. The IP Location results include network registration details. Look for the abuse contact email, which is typically in the format [email protected].
3. Verify the port is open. Use the Port Scanner to confirm that the attacking IP has port 22 (SSH) or 3389 (RDP) open — this helps confirm the host is actively running services and is not simply a spoofed address.

For major cloud providers, abuse contacts are well-known:

If the WHOIS record shows no obvious abuse email, look for the network's abuse-mailbox in the RDAP/WHOIS output, or check the RIR database (ARIN, RIPE, APNIC) directly.

Brute Force Abuse Report Email Template

Use this template when reporting to the ISP or hosting provider. Replace the bracketed placeholders with your actual data.

Subject: SSH Brute Force Attack from [ATTACKING_IP] — Abuse Report

To whom it may concern,

I am reporting a brute force SSH attack originating from IP address
[ATTACKING_IP] (ASN: [ASN_NUMBER], [ISP_NAME]) against my server
[YOUR_SERVER_IP].

Attack summary:
- Source IP: [ATTACKING_IP]
- Target: [YOUR_SERVER_IP] port 22 (SSH)
- Time range: [START_TIME] to [END_TIME] (UTC)
- Total failed login attempts: [COUNT]
- Usernames attempted: root, admin, deploy, ubuntu, test, oracle, [others]

Raw log evidence (from /var/log/auth.log):

[PASTE 10-20 LOG LINES HERE]

Attempt count summary:
[PASTE OUTPUT OF THE uniq -c COMMAND]

This IP has been automatically banned by fail2ban on my server. I am
requesting that you investigate this host for compromise or malicious
use and take appropriate action.

Thank you,
[YOUR_NAME]

For RDP attacks, adjust the template: change "SSH" to "RDP," reference port 3389, cite Event ID 4625 entries, and include the PowerShell output instead of auth.log lines.

Where to Report

ISP / Hosting Provider Abuse Desk

The primary destination for your report is the abuse desk of the ISP or hosting provider that owns the attacking IP. Most providers have an abuse@ email address and are obligated to act under their acceptable use policies.

Cloud Provider Abuse Forms

Major cloud providers have dedicated abuse reporting portals that are often faster than email:

• AWS: AWS Trust & Safety abuse form (linked from their abuse page)
• GCP: Google Cloud abuse form in the console
• Azure: Microsoft Security Response Center portal

National CERTs and Law Enforcement

For persistent, large-scale attacks, consider escalating to your national CERT. In the US, this is CISA. In the EU, contact your country's CERT (CERT-EU, BSI in Germany, ANSSI in France). Law enforcement involvement is typically reserved for attacks that result in actual compromise — see my guide on reporting a hacked server for that scenario.

Sub-Scenarios

SSH Password Brute Force

The most common variant. Automated tools like Hydra or Medusa cycle through username/password combinations at high speed. Log signature: repeated "Failed password for" entries from the same IP. These attacks are opportunistic and rarely targeted — the bots scan entire IP ranges.

SSH Key Enumeration

Some attackers probe for valid usernames by observing timing differences in authentication responses, or attempt to authenticate with stolen private keys. Log signature: "Connection closed by authenticating user" or "Received disconnect from" without a preceding password failure. Include these entries in your report if you see them.

RDP Credential Stuffing

Credential stuffing uses username/password pairs leaked from breaches on other platforms. Unlike pure brute force, the combinations are realistic and may include actual email addresses as usernames. Log signature: Event ID 4625 with Logon Type 10, where the attempted usernames include email addresses or names rather than generic service accounts. This is particularly dangerous because a match is more likely if any user reuses passwords.

WordPress and Web Application Login Brute Force

Brute force is not limited to SSH and RDP. WordPress sites see constant attacks against /wp-login.php and /xmlrpc.php. Check your web server access logs:

grep "POST /wp-login.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

The same reporting process applies: extract the evidence, find the abuse contact for the attacking IP, and send a report. If the attack exploits xmlrpc.php for amplified brute force (system.multicall), mention this specifically because it suggests the attacker is using a known WordPress vulnerability vector.

You can verify whether common attack ports are exposed on suspicious IPs by running a scan with the Port Scanner.

What to Expect After Reporting

Response timelines vary significantly by provider:

• Major cloud providers (AWS, GCP, Azure): Typically respond within 24-48 hours. They have dedicated abuse teams and automated systems. Compromised instances are often shut down within hours.
• Large hosting companies (OVH, Hetzner, DigitalOcean): Usually respond within 1-3 business days. Most have clear abuse workflows.
• Small ISPs and regional providers: Response times range from days to weeks. Follow up after 7 days if you receive no acknowledgment.
• Bulletproof hosting and unresponsive providers: Some providers deliberately ignore abuse reports. If you get no response after two follow-ups, escalate to the upstream provider (the network that provides transit to the offending ASN) or report to the relevant RIR abuse contact.

Keep copies of all your reports and any responses. If the same IP continues attacking after you have reported it, include your original report reference in follow-up communications. Persistent patterns from the same provider or network can also be reported to threat intelligence platforms like AbuseIPDB to warn other administrators.

For attacks that involve actual server compromise rather than just brute force attempts, see my guide on reporting a hacked server or compromise. For port scanning activity that often precedes brute force attacks, see reporting port scanning and network reconnaissance.

Prevention Tips

Reporting is reactive. These measures reduce or eliminate brute force attacks proactively:

• Disable password authentication for SSH. Switch to key-based authentication exclusively. In /etc/ssh/sshd_config, set PasswordAuthentication no and ChallengeResponseAuthentication no. This makes password brute force impossible.
• Run fail2ban or SSHGuard. Automatically ban IPs after a configurable number of failed attempts. Default thresholds of 5 failures in 10 minutes are reasonable.
• Change the SSH port. Moving SSH from port 22 to a non-standard port (e.g., 2222 or higher) eliminates the vast majority of automated scanning. This is not security — it is noise reduction.
• Restrict access with a firewall. Use ufw, iptables, or cloud security groups to allow SSH only from known IP addresses or ranges. If you need broader access, consider a VPN or WireGuard tunnel.
• Enable Network Level Authentication (NLA) for RDP. NLA requires authentication before a full RDP session is established, significantly reducing the attack surface. In Windows, go to System Properties, Remote tab, and check "Allow connections only from computers running Remote Desktop with Network Level Authentication."
• Use a VPN or jump box. Never expose SSH or RDP directly to the internet if you can avoid it. Route all remote access through a VPN (WireGuard, OpenVPN) or a hardened bastion/jump host.
• Implement account lockout policies for RDP. In Group Policy, configure account lockout thresholds to lock accounts after a number of failed attempts. Be cautious with this on shared systems to avoid denial-of-service via intentional lockouts.
• Monitor and alert. Set up log monitoring to alert you when brute force patterns emerge so you can report quickly while the evidence is fresh.