How to protect a Windows VPS from RDP brute force attacks

Every Windows VPS exposed to the public internet starts receiving RDP login attempts within minutes of boot. Bots scan entire IP ranges looking for port 3389 open and fire dictionaries of common passwords at accounts like Administrator, admin, user and variations. On an unprotected VPS the Event Log fills with Event ID 4625 (logon failure) in a few hours — and a single weak password is all it takes for an attacker to get in.

This tutorial is for Windows sysadmins who recently provisioned a VPS and want to reduce the RDP attack surface before putting the server into production. The measures here don’t require third-party software — they only use native features of Windows Server 2019/2022/2025. Estimated time: 30 to 45 minutes to apply all layers.

The approach is layered — no single measure is enough on its own. You’ll apply four defenses: an account lockout policy, an RDP port change, firewall restriction by source IP and automatic blocking of offending IPs via an event-triggered Scheduled Task.

Prerequisites

Before starting, open Event Viewer at Windows Logs > Security and filter by Event ID 4625. On a VPS that’s been exposed for more than 24 hours, you’ll typically see hundreds of attempts coming from IPs in China, Russia, Brazil and the US. That’s the baseline we’re going to crush.

Apply an account lockout policy

The lockout policy makes Windows temporarily disable an account after N failed attempts. Without it, an attacker can fire thousands of passwords per minute at the Administrator account. With a 5-attempt lockout and a 30-minute block, the attacker can test at most 240 passwords per day per account — making dictionary attacks unfeasible.

Computer Configuration > Windows Settings > Security Settings >
Account Policies > Account Lockout Policy

gpupdate /force

net accounts

Change the default RDP port

Switching from 3389 to a high port (above 49152, the dynamic range) eliminates the noise from automated scanners that only look for the default port. It’s not real security against a targeted attack — nmap -p- IP still finds it — but it drops Event ID 4625 by 90%+ on exposed VPSes.

HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

New-NetFirewallRule -DisplayName "RDP Custom Port 54289 TCP" `
  -Direction Inbound -LocalPort 54289 -Protocol TCP -Action Allow

New-NetFirewallRule -DisplayName "RDP Custom Port 54289 UDP" `
  -Direction Inbound -LocalPort 54289 -Protocol UDP -Action Allow

Restart-Service TermService -Force

Restrict RDP by source IP

The most effective measure: the firewall only accepts RDP connections from specific IPs. Works well if your team accesses from fixed IPs (office, corporate VPN). It doesn’t work if you need to access from residential networks with dynamic IPs — in that case, consider the WireGuard tunnel alternative.

(Invoke-WebRequest -Uri "https://ifconfig.me/ip").Content

Set-NetFirewallRule -DisplayName "RDP Custom Port 54289 TCP" `
  -RemoteAddress @("203.0.113.10", "198.51.100.42")

Get-NetFirewallRule -DisplayName "RDP Custom Port 54289 TCP" |
  Get-NetFirewallAddressFilter

Automatically block offending IPs

Even with lockout and a changed port, if you can’t restrict by source IP (public-facing service, distributed team), configure dynamic blocking: every time Event ID 4625 appears above a threshold, a Scheduled Task fires a PowerShell script that adds the source IP to a blocking firewall rule.

param([string]$EventRecordID)

$event = Get-WinEvent -LogName Security -FilterXPath `
  "*[System[EventRecordID=$EventRecordID]]"

$ip = ($event.Properties | Where-Object { $_.Value -match '^\d+\.\d+\.\d+\.\d+$' } |
  Select-Object -First 1).Value

if (-not $ip -or $ip -eq "127.0.0.1") { exit }

$ruleName = "AutoBlock-$ip"
if (-not (Get-NetFirewallRule -DisplayName $ruleName -ErrorAction SilentlyContinue)) {
    New-NetFirewallRule -DisplayName $ruleName -Direction Inbound `
      -RemoteAddress $ip -Action Block | Out-Null
    Add-Content "C:\Scripts\blocked-ips.log" "$(Get-Date -Format o) BLOCKED $ip"
}

-ExecutionPolicy Bypass -File C:\Scripts\BlockBruteforceIP.ps1 -EventRecordID $(EventRecordID)

Get-NetFirewallRule | Where-Object DisplayName -like "AutoBlock-*"

Verification

After applying the four layers, confirm each one is in place by running:

# Lockout policy
net accounts | findstr "Lockout"

# New RDP port active
Get-ItemProperty "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
  | Select-Object PortNumber

# Firewall accepts connection on the new port
Test-NetConnection -ComputerName localhost -Port 54289

# Account actually hardened — try a bad login 5x from another IP
# and look for Event ID 4740 (Account Locked Out) in the Event Log
Get-WinEvent -LogName Security -MaxEvents 50 |
  Where-Object Id -eq 4740 | Format-Table TimeCreated, Message -AutoSize

Wait 24 hours and revisit Event Viewer. You should see Event ID 4625 drop from hundreds/thousands per day to dozens or zero, depending on how exposed the original port was before the change.

Next steps

• Enable NLA (Network Level Authentication) if it isn’t on — it requires authentication before the full RDP handshake, shrinking the attack surface to pre-auth vulnerabilities.
• Consider moving off native RDP to Azure Bastion or an RDS gateway with MFA if the environment justifies it.
• Set up successful logon auditing (Event ID 4624) and email alerts for logins outside business hours.
• Take periodic backups of the registry (HKLM\System\CurrentControlSet\Control\Terminal Server) — so you can revert quickly if something breaks.
• If you’re provisioning a new VPS for production, a Hostini VPS Windows already ships with out-of-band console access through the panel — so even if you lock yourself out of RDP while applying these rules, recovery doesn’t require a support ticket.