Detect and Block RDP Brute-Force Attempts on Windows Server 2025

In short

If a Windows Server is receiving repeated failed Remote Desktop logons, start with evidence, not random firewall changes. Windows Security event 4625 records failed logon attempts. In our current Raff Windows Server 2025 validation, repeated public RDP probes were logged as Logon Type 3 during NLA pre-authentication, while Microsoft defines Logon Type 10 as RemoteInteractive for completed Remote Desktop interactive logon attempts.

That distinction matters: do not filter only for Type 10 and assume you have found every RDP-related failure. Instead, correlate the failed logon event with the source IP, targeted username, NLA state, RDP exposure, and timing.

A practical response flow is:

Repeated RDP login failures
        |
        v
Confirm Security auditing
        |
        v
Inspect Event 4625
        |
        v
Group failures by source IP / account
        |
        v
Validate source is not legitimate
        |
        v
Block confirmed source on the RDP port
        |
        v
Re-check logs and legitimate access
        |
        v
Reduce future exposure with allowlisting,
VPN/RD Gateway, NLA, MFA, and monitoring

For preventive RDP configuration such as Network Level Authentication, IP allowlisting, administrator-account hygiene, and account lockout policy, use Secure Direct RDP on a Windows VPS. For broader firewall design, use Configure Windows Firewall on a Windows VPS.

Safety rule: Do not auto-block every failed login source without review. Shared NAT addresses, mistyped credentials, monitoring systems, administrators on changing networks, and internal infrastructure can create legitimate failures. Confirm the source and preserve a recovery path before changing remote-access rules.

What an RDP brute-force pattern looks like

One failed login is not a brute-force attack.

Look for combinations such as:

During Raff's Windows Server 2025 validation, a public RDP endpoint received hundreds of failed attempts from individual source IPs within a short observation window. The probes tried usernames such as Admin, administrator, ADMINISTRATOR, Temp, and other common account names. That is consistent with automated credential probing rather than a single user mistyping a password.

A real incident review should correlate failed logons, successful logons, account changes, network exposure, and administrator activity. Do not conclude that the server was compromised only because event 4625 exists.

Event 4625 is the main failed-logon signal

Microsoft documents Security event 4625 — An account failed to log on for failed authentication attempts on Windows systems.

Useful fields include:

• TargetUserName — account that was attempted;
• LogonType — type of Windows logon;
• IpAddress — remote source when Windows records one;
• Status and SubStatus — failure details;
• WorkstationName — source workstation where available;
• authentication package and process information.

Microsoft defines Logon Type 10 as RemoteInteractive, the logon type associated with Remote Desktop/Terminal Services interactive access.

However, with NLA enabled, some failed RDP authentication attempts can be rejected before a RemoteInteractive session is established. In our Raff Windows Server 2025 test, the repeated public probes appeared as Logon Type 3 and were still clearly associated with the server's exposed RDP endpoint by timing, source IPs, username patterns, and active connections to the RDP port.

The operational lesson is simple: do not hard-code your investigation to Type 10 only. Use the event fields and the actual RDP context around the server.

Step 1 — Record the Windows Server and RDP environment

Before changing anything, record the system and current RDP configuration.

Run PowerShell as Administrator:

cls

Write-Host "=== WINDOWS SERVER ==="
Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Write-Host "`n=== HOSTNAME ==="
hostname

Write-Host "`n=== RDP SERVICE ==="
Get-Service TermService |
    Select-Object Name, Status, StartType

Write-Host "`n=== RDP PORT ==="
$RdpPort = (Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name PortNumber).PortNumber
$RdpPort

Write-Host "`n=== NLA ==="
Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name UserAuthentication |
  Select-Object UserAuthentication

A UserAuthentication value of 1 means Network Level Authentication is required.

Do not change the RDP port or NLA merely to perform this investigation. This first step is evidence collection.

Step 2 — Confirm failed-logon auditing is available

Check the current Logon audit policy:

auditpol /get /subcategory:"Logon"

You want failure auditing available so failed authentication is recorded.

If this is a standalone lab and failure auditing is not enabled, Microsoft supports configuring advanced audit policy with auditpol. A local example is:

auditpol /set /subcategory:"Logon" /success:enable /failure:enable

In a domain-managed environment, Group Policy can control the effective setting. Do not create conflicting local policy without understanding the management source.

Step 3 — Inspect recent Event 4625 failures

Start with a simple query for the last 24 hours:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddHours(-24)
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, Message |
Select-Object -First 20

This proves whether the server is recording failed logons, but the message text is too verbose for useful incident analysis.

The next step extracts the structured XML fields.

Step 4 — Extract the fields you need from Event 4625

Run:

$Failures = Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddHours(-1)
} -ErrorAction SilentlyContinue | ForEach-Object {

    $EventXml = [xml]$_.ToXml()
    $Data = @{}

    foreach ($Item in $EventXml.Event.EventData.Data) {
        $Data[$Item.Name] = $Item.'#text'
    }

    [pscustomobject]@{
        TimeCreated    = $_.TimeCreated
        EventID        = $_.Id
        TargetUserName = $Data['TargetUserName']
        LogonType      = $Data['LogonType']
        IpAddress      = $Data['IpAddress']
        Workstation    = $Data['WorkstationName']
        Status         = $Data['Status']
        SubStatus      = $Data['SubStatus']
    }
}

$Failures |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 30 |
    Format-Table -AutoSize

This gives you the fields that matter for investigation:

TimeCreated
EventID
TargetUserName
LogonType
IpAddress
Workstation
Status
SubStatus

During our current Raff validation, the suspicious RDP probes showed:

• Event ID 4625;
• Logon Type 3;
• multiple public source IPs;
• repeated attempts against common administrator-style usernames;
• status 0xc000006d for logon failure;
• substatus 0xc0000064 on many attempts, indicating that the attempted username did not exist.

If you publish screenshots from a real server, redact public IP addresses, real usernames, or domain details unless they are deliberately safe to expose.

Step 5 — Group failed attempts by source IP

A single event is less useful than the pattern.

Group the parsed failures:

$Failures |
    Where-Object {
        $_.IpAddress -and
        $_.IpAddress -notin @('-', '127.0.0.1', '::1')
    } |
    Group-Object IpAddress |
    Sort-Object Count -Descending |
    ForEach-Object {
        $Group = $_.Group

        [pscustomobject]@{
            IpAddress      = $_.Name
            FailedAttempts = $_.Count
            LogonTypes     = (($Group.LogonType | Sort-Object -Unique) -join ', ')
            Usernames      = (($Group.TargetUserName | Sort-Object -Unique) -join ', ')
            FirstSeen      = ($Group.TimeCreated | Measure-Object -Minimum).Minimum
            LastSeen       = ($Group.TimeCreated | Measure-Object -Maximum).Maximum
        }
    } |
    Format-Table -AutoSize

This helps distinguish:

• one user repeatedly mistyping a password;
• one attacking IP testing several accounts;
• sustained activity from one address;
• a distributed pattern involving many addresses.

In the Raff lab, this grouping made the pattern obvious: individual sources had hundreds of failures, while other addresses appeared only once or twice. That is a much stronger signal than reading isolated Event Viewer entries.

For a busy public server, retain or forward this evidence rather than relying only on the rolling local Security log.

Step 6 — Confirm the source before blocking it

Do not convert every IP in the table directly into a firewall block.

Before blocking, ask:

• Is this our office NAT address?
• Is this an administrator who recently changed a password?
• Is this a VPN egress IP?
• Is this an MSP or monitoring system?
• Is the targeted account expected to connect remotely?
• Is the address already on an approved allowlist?
• Is one public IP shared by many legitimate users?

A false-positive block can create an outage, especially when several administrators share one corporate egress IP.

You can also inspect current established connections to the actual RDP port before blocking a source:

$RdpPort = (Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name PortNumber).PortNumber

Get-NetTCPConnection `
    -LocalPort $RdpPort `
    -State Established |
Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort |
Format-Table -AutoSize

An established TCP connection to the RDP port does not prove successful Windows authentication, but it helps distinguish active network connections while you verify which source is your own current administrative session.

Step 7 — Discover the actual RDP port before writing the rule

Do not assume every server still uses TCP 3389.

Run:

$RdpPort = (Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name PortNumber).PortNumber

Write-Host "RDP port: $RdpPort"

In our Raff Windows Server 2025 validation, the test VM used the default RDP port 3389.

Changing the RDP port is not a primary anti-brute-force control, but the blocking rule still needs to match the port actually used by the server.

Step 8 — Block one confirmed hostile source on the RDP port

Use the exact confirmed IP.

The address below is an RFC 5737 documentation address and will not represent a real attacker:

$BlockedIP = '203.0.113.45'
$RdpPort = (Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name PortNumber).PortNumber

New-NetFirewallRule `
  -DisplayName "RDP Brute Force Block TCP - $BlockedIP" `
  -Direction Inbound `
  -Action Block `
  -Protocol TCP `
  -LocalPort $RdpPort `
  -RemoteAddress $BlockedIP `
  -Profile Any

If the environment intentionally uses RDP over UDP as well, create the corresponding UDP block for the same confirmed source:

New-NetFirewallRule `
  -DisplayName "RDP Brute Force Block UDP - $BlockedIP" `
  -Direction Inbound `
  -Action Block `
  -Protocol UDP `
  -LocalPort $RdpPort `
  -RemoteAddress $BlockedIP `
  -Profile Any

Microsoft's New-NetFirewallRule supports source scoping with -RemoteAddress, including single IPv4/IPv6 addresses, ranges, and subnets.

For incident response, prefer an exact IP unless you have evidence that an entire subnet should be blocked. Blocking broad ranges can affect legitimate users who share the same provider or network.

In our controlled test, we created a rule against one confirmed high-volume probe source and verified that Windows Firewall reported the rule as Enabled, Inbound, and Block.

Step 9 — Verify exactly what the firewall rule blocks

Do not trust the command merely because it returned without an error.

Run:

Get-NetFirewallRule -DisplayName "RDP Brute Force Block*" |
    Select-Object DisplayName, Enabled, Direction, Action, Profile |
    Format-Table -AutoSize

Then inspect the address scope:

Get-NetFirewallRule -DisplayName "RDP Brute Force Block*" |
    Get-NetFirewallAddressFilter |
    Select-Object Name, RemoteAddress |
    Format-Table -AutoSize

And inspect the port/protocol scope:

Get-NetFirewallRule -DisplayName "RDP Brute Force Block*" |
    Get-NetFirewallPortFilter |
    Select-Object Name, Protocol, LocalPort |
    Format-Table -AutoSize

Verify that:

• the rule is enabled;
• direction is inbound;
• action is block;
• source address is the intended IP only;
• port is the actual RDP port;
• protocol matches the intended RDP path.

That is the exact validation we used in the current Raff test before considering the source blocked.

Step 10 — Test legitimate RDP before closing the current session

When changing firewall rules remotely, keep the current administrator session open.

From a separate approved client, confirm that normal RDP access still works.

On a Windows client:

Test-NetConnection YOUR_SERVER_IP -Port 3389

If the server uses a custom RDP port, substitute that port.

Then perform a real login using an approved administrator account.

The acceptance test is:

Confirmed hostile/test source
→ blocked from RDP

Approved administrator source
→ still connects normally

If approved access fails, remove the new block rule from the existing working session or use the provider console/recovery path.

Step 11 — Re-check event activity after blocking

Continue monitoring 4625 events:

$Since = (Get-Date).AddMinutes(-30)

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4625
    StartTime=$Since
} -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message |
    Select-Object -First 20

A Windows Firewall block occurs before Windows authentication. That means blocked connection attempts may no longer create the same 4625 authentication events because the source cannot reach the login path.

This is expected.

Use firewall logging or upstream network telemetry if you need visibility into packets blocked before authentication.

Step 12 — Remove a temporary test block safely

For a lab or time-limited incident block, remove the exact rule after validation:

$BlockedIP = '203.0.113.45'
$RuleName = "RDP Brute Force Block TCP - $BlockedIP"

Remove-NetFirewallRule -DisplayName $RuleName -ErrorAction SilentlyContinue

$Rule = Get-NetFirewallRule -DisplayName $RuleName -ErrorAction SilentlyContinue

if ($null -eq $Rule) {
    Write-Host "RDP brute-force test rule removed successfully."
} else {
    $Rule | Select-Object DisplayName,Enabled,Direction,Action
}

This gives you a clean rollback check instead of assuming the rule was removed.

Do not build an automatic blocker directly from raw 4625 events without safeguards

It is tempting to create a scheduled PowerShell script that automatically blocks every address after five failures.

That can create its own outage.

Before automating, you need at least:

• permanent allowlist for trusted administrator/VPN addresses;
• exclusion for loopback and internal management ranges;
• threshold and time-window logic;
• duplicate-rule handling;
• automatic expiry/unblock logic;
• logging of every block decision;
• false-positive protection;
• recovery path if the automation misbehaves;
• testing against real NAT/VPN/admin workflows.

For a small Windows VPS, manual review + narrow block + stronger access architecture is often safer than an untested home-grown IPS script.

If repeated RDP attacks are a normal condition, reduce exposure instead of maintaining an ever-growing IP blocklist.

Account lockout slows password guessing but can also become a DoS control

Account lockout is useful, but it has trade-offs.

Microsoft publishes different recommended values in different baseline contexts. The important rule is not to copy one number blindly.

For a standalone server, inspect local policy:

net accounts

For an Active Directory domain, inspect the effective domain policy:

Get-ADDefaultDomainPasswordPolicy |
    Select-Object LockoutThreshold, LockoutDuration, LockoutObservationWindow

If fine-grained password policies exist, privileged users can have a different effective policy from the domain default.

Lockout policy should complement—not replace—source restrictions, NLA, MFA, gateway/VPN architecture, strong credentials, and monitoring.

Successful login after a brute-force pattern needs immediate review

The most important event is not always the failed login.

If repeated 4625 failures are followed by a successful logon for the same account or source, investigate immediately.

Review:

• Security event 4624 successful logons;
• administrator and group membership changes;
• new local/domain users;
• scheduled tasks;
• newly installed services;
• PowerShell activity;
• Defender detections;
• unusual processes;
• outbound network connections;
• firewall changes;
• password resets;
• application logs.

Blocking the source IP after compromise is not enough. Treat a suspicious successful authentication as an incident-response problem, not merely an RDP tuning problem.

Stronger long-term defenses are better than a growing blocklist

A blocklist handles known sources. It does not stop the next source address.

For a one-admin server with a stable IP, Secure Direct RDP on a Windows VPS provides the preventive configuration.

For multiple users or changing networks, Remote Desktop Gateway vs Direct RDP is the better architecture decision page.

Common mistakes during RDP brute-force response

Filtering only for Logon Type 10

Type 10 is the RemoteInteractive logon type, but an NLA-protected RDP attempt can fail before that stage. In our Raff validation, repeated public RDP probes appeared as Type 3. Use the server context and event fields, not one logon-type filter alone.

Blocking before identifying the actual source

Do not block a corporate NAT, VPN exit IP, MSP address, or legitimate administrator because it generated a few failed attempts.

Blocking port 3389 when the server uses a custom RDP port

Read the actual PortNumber first.

Creating an allow rule when you intended to create a block

Always verify Action, Direction, RemoteAddress, Protocol, and LocalPort after the rule is created.

Blocking an entire subnet from one suspicious IP

Start with the smallest scope supported by the evidence.

Closing the current RDP session before testing a second approved connection

Keep the working session open until the replacement access path is proven.

Treating IP blocks as the permanent security architecture

Attackers can change source addresses. Reduce the reachable attack surface instead.

Resetting account lockout policy to extreme values during an incident

Aggressive lockout settings can turn password attacks into denial-of-service against legitimate users. Use the organization's documented baseline.

RDP brute-force response checklist

Before closing the incident, confirm:

• Event 4625 failures were verified.
• Logon type was reviewed in context rather than assumed.
• Source IPs and targeted accounts were documented.
• Approved administrator/VPN addresses were excluded from blocking.
• Confirmed hostile sources were blocked with narrow firewall rules.
• Block rule protocol and RDP port were verified.
• Legitimate RDP access was tested from a second session/client.
• Security logs were checked for successful logons after the failure pattern.
• Targeted credentials were reviewed/reset if compromise is plausible.
• NLA is enabled.
• Direct RDP exposure was reviewed.
• VPN, RD Gateway, source allowlisting, or MFA was considered for long-term protection.
• Temporary block rules have an owner and removal/expiry decision.
• Security evidence is retained outside the live server when the incident is material.

Where Raff fits

Raff Windows VM provides the Windows Server infrastructure where administrators can apply Windows Firewall, Security auditing, NLA, account policy, RD Gateway, and other operating-system controls.

For a production Windows workload, the stronger architecture is usually not:

Public RDP
+
large attacker blocklist

It is closer to:

Raff Windows VM
        |
        +--> restricted administrative access
        +--> NLA
        +--> strong named accounts
        +--> Windows Firewall
        +--> monitoring
        +--> backup/recovery
        `--> VPN / RD Gateway / MFA where required

For MSPs, the repeatable value is to deploy the same access-security baseline across client Windows VMs, then use event evidence to investigate exceptions rather than rebuilding the security model during every incident.

Raff provides the Windows VM infrastructure. Windows security policy, firewall rules, identity configuration, and incident response remain administrator responsibilities unless a separate managed service explicitly covers them.

Frequently asked questions

Which Windows event shows failed RDP logins?

Security event 4625 records failed Windows logon attempts. Microsoft defines Logon Type 10 as RemoteInteractive, but do not assume every NLA-protected RDP failure will reach Type 10. In our Windows Server 2025 Raff validation, repeated public RDP probes appeared as Logon Type 3 during pre-authentication.

Does every event 4625 mean an RDP attack?

No. Event 4625 can be generated by many kinds of failed authentication. Inspect the source IP, targeted username, timing, logon type, NLA state, and whether the source is reaching the RDP port before classifying it as Remote Desktop brute-force activity.

How do I find which IP is brute-forcing RDP?

Parse recent Security event 4625 entries, extract the IpAddress field, group failures by source IP, and compare attempt counts and usernames. Confirm the address is not an approved administrator, VPN, or corporate NAT before blocking it.

Can Windows Firewall block one RDP attacker IP?

Yes. New-NetFirewallRule supports -RemoteAddress so you can create an inbound block rule for a confirmed source and scope it to the actual RDP port and protocol.

Should I automatically block an IP after a certain number of failed RDP logins?

Not without safeguards. Automatic blocking needs allowlists, expiry logic, duplicate handling, false-positive protection, logging, and a recovery path. For small environments, manual confirmation plus stronger RDP exposure controls is usually safer.

Does account lockout stop RDP brute force?

It slows repeated password guessing, but it can also let attackers intentionally lock legitimate accounts. Use lockout policy as one layer alongside NLA, source restrictions, MFA, gateway/VPN architecture, strong passwords, and monitoring.

Is changing the RDP port enough to stop brute-force attacks?

No. It may reduce unsophisticated scanning temporarily, but it does not provide meaningful identity protection once the service is discovered. Restrict who can reach RDP and strengthen authentication instead.

What should I do if a successful RDP login appears after many failures?

Treat it as a potential security incident. Review successful logons, account/group changes, processes, scheduled tasks, services, PowerShell activity, Defender detections, firewall changes, and credentials rather than only blocking the source IP.

What's next

• Secure Direct RDP on a Windows VPS
• Configure Windows Firewall on a Windows VPS
• Windows Server Hardening Checklist
• Remote Desktop Gateway vs Direct RDP
• Add MFA to Remote Desktop Services
• Raff Windows VM

Sources

• Microsoft Learn — Security Event 4625, An account failed to log on: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4625
• Microsoft Learn — New-NetFirewallRule (Windows Server 2025 PowerShell): https://learn.microsoft.com/en-us/powershell/module/netsecurity/new-netfirewallrule?view=windowsserver2025-ps
• Microsoft Learn — Remote Desktop and Network Level Authentication: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-allow-access
• Microsoft Learn — Remote Desktop access from outside a network: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-allow-outside-access
• Microsoft Learn — Configure Security Baselines for Windows Server 2025: https://learn.microsoft.com/en-us/windows-server/security/osconfig/osconfig-how-to-configure-security-baselines
• Microsoft Learn — Fine-grained password policies for Active Directory: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/fine-grained-password-policies
• Microsoft Learn — Account lockout threshold remediation guidance: https://learn.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/set-the-account-lockout-threshold-to-the-recommended-value
• Sources verified: 2026-09-01