How to Detect RDP Brute Force Attacks Using Windows Event Logs
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Remote Desktop Protocol brute force is the leading initial access technique in ransomware incidents. Attackers scan the internet for open port 3389, then hammer credentials using tools like Hydra, Crowbar, or Mimikatz's sekurlsa. The detection is straightforward: Windows Security logs every failed authentication attempt as Event ID 4625. The challenge is tuning thresholds to catch attacks without flooding analysts with legitimate password-reset noise. This guide walks through building a layered RDP brute force detection system from raw event logs to automated response.
Enable the Right Audit Policies
RDP brute force detection requires two audit policies enabled via Group Policy or local security policy. Navigate to Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration. Under Logon/Logoff, enable 'Audit Logon' for both Success and Failure. Under Account Logon, enable 'Audit Credential Validation' for Failure. Verify with: auditpol /get /category:"Logon/Logoff". Both should show 'Success and Failure'. Without these enabled, Event ID 4625 will not appear in Security logs regardless of failed attempts. In domain environments, apply this GPO to all domain controllers and member servers with RDP enabled. Confirm policy application: gpresult /r /scope computer and check the applied GPOs list.
Understand the Key Event Fields
Event ID 4625 contains several fields critical for RDP-specific detection. Filter on Logon Type 10 (RemoteInteractive) to isolate RDP failures from console, service, and network logons. Key fields: SubjectAccountName (the account being attempted), IpAddress (the source IP), IpPort (source port), LogonType (must be 10 for RDP), and FailureReason. In XML view: <Data Name="LogonType">10</Data>. The IpAddress field contains the actual attacking IP when NLA is enabled. Without NLA, IpAddress may show the local machine's IP instead of the remote attacker, making detection much harder. Event ID 4624 Logon Type 10 with AuthenticationPackageName of NTLM or Kerberos immediately after a 4625 burst signals successful compromise.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Build PowerShell Detection Queries
Query Security event logs for RDP brute force with PowerShell:
$StartTime = (Get-Date).AddHours(-1)
$Events = Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625
StartTime = $StartTime
} | Where-Object {
($_.Properties[8].Value -eq 10) # LogonType 10 = RDP
}
$Events | Group-Object { $_.Properties[19].Value } |
Where-Object { $_.Count -gt 20 } |
Select-Object Count, Name |
Sort-Object Count -Descending
Property index 19 is the IpAddress field. The Count -gt 20 threshold means more than 20 RDP failures from a single IP in the last hour. Tune this threshold based on your environment: a single legitimate user retrying a forgotten password generates 3-5 failures, never 50+. For domain controllers, lower the threshold to 10 since legitimate RDP to DCs should be rare. Run as a scheduled task every 15 minutes and email results when the output is non-empty.
Create SIEM Correlation Rules
For Splunk, create a brute force correlation rule:
index=wineventlog EventCode=4625 Logon_Type=10
| bucket _time span=5m
| stats count as fail_count, dc(Account_Name) as unique_accounts by _time, Source_Network_Address
| where fail_count > 30
| eval attack_type=if(unique_accounts > 5, "credential_stuffing", "brute_force")
| table _time, Source_Network_Address, fail_count, unique_accounts, attack_type
For Microsoft Sentinel (KQL):
SecurityEvent
| where EventID == 4625 and LogonType == 10
| where TimeGenerated > ago(5m)
| summarize FailCount=count(), UniqueAccounts=dcount(TargetUserName) by IpAddress, bin(TimeGenerated, 5m)
| where FailCount > 30
| extend AttackType = iff(UniqueAccounts > 5, "CredentialStuffing", "BruteForce")
The UniqueAccounts dimension distinguishes single-account brute force (trying one username repeatedly) from credential stuffing (trying many username/password pairs). Credential stuffing often targets valid usernames harvested from data breaches.
Detect Successful Post-Brute-Force Logins
A 4625 burst followed by a 4624 from the same IP within minutes is the highest-confidence ransomware precursor indicator. Splunk correlation:
index=wineventlog EventCode=4625 Logon_Type=10
| stats count as fail_count by Source_Network_Address, span=5m
| where fail_count > 20
| join Source_Network_Address [
search index=wineventlog EventCode=4624 Logon_Type=10 earliest=-10m
| rename Source_Network_Address as Source_Network_Address
]
| table _time, Source_Network_Address, fail_count, Account_Name, Workstation_Name
This join finds IPs that generated 20+ failures and then successfully authenticated. Alert this immediately as Priority 1: initiate incident response. Also watch for Event ID 4778 (RDP session reconnected) following a suspicious 4624, which indicates the attacker is actively working in an established session. Event ID 4648 (explicit credentials used during session) indicates lateral movement from the compromised host.
Automate IP Blocking via Windows Firewall
Automate blocking of confirmed attacking IPs with a PowerShell script that reads from your SIEM or a blocked-IPs text file:
$BlockedIPs = Get-Content C:\Security\blocked-rdp-ips.txt
foreach ($IP in $BlockedIPs) {
$RuleName = "Block-RDP-Brute-$IP"
if (-not (Get-NetFirewallRule -DisplayName $RuleName -ErrorAction SilentlyContinue)) {
New-NetFirewallRule -DisplayName $RuleName `
-Direction Inbound `
-Protocol TCP `
-LocalPort 3389 `
-RemoteAddress $IP `
-Action Block `
-Profile Any
Write-EventLog -LogName Security -Source "RDP-BlockScript" -EventId 9001 `
-EntryType Warning -Message "Blocked RDP brute force source: $IP"
}
}
For domain environments, push firewall rules via GPO using the Windows Firewall with Advanced Security GPO settings. NetFirewallRule cmdlets require elevation: run as a scheduled task under a service account with local admin rights. Log each block as a custom Security event (EventId 9001+) for auditing. Review and expire blocks monthly to avoid permanently blocking legitimate IPs that may have been spoofed or NATed.
Harden RDP to Reduce Attack Surface
Detection catches attacks in progress; hardening prevents them from succeeding. Required controls: (1) Enable Network Level Authentication: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Require NLA. NLA forces authentication before the RDP session is fully established, preventing unauthenticated connection probing. (2) Restrict RDP access to specific IPs via Windows Firewall or network ACLs: only jump servers or VPN gateway IPs should reach port 3389. (3) Enable account lockout: after 5 failed attempts, lock for 30 minutes: this makes brute force infeasible (Security Policy > Account Lockout Policy). (4) Consider RDP Gateway instead of direct RDP exposure: the gateway authenticates via HTTPS before forwarding to internal hosts, adding a layer with certificate validation. (5) Enable RDP logging at the gateway level for central visibility across all RDP sessions.
The bottom line
RDP brute force detection requires auditing enabled (Event ID 4625 with Logon Type 10), a threshold-based alerting rule tuned for your environment (typically 20-50 failures per IP per 5 minutes), and a separate correlation for successful logins following a failure burst. Automate IP blocking to cut attacker dwell time. The minimum viable control set: NLA enabled, account lockout policy active, and 4625/4624 correlation alerts sending to an on-call queue.
Frequently asked questions
What Event ID do I use to detect RDP brute force in Windows Security logs?
Use Event ID 4625 filtered to Logon Type 10 (RemoteInteractive) to detect failed RDP authentication attempts. Group by source IP address and alert when any single IP generates more than 20-30 failures within a 5-minute window. Correlate with Event ID 4624 Logon Type 10 to detect successful logins following a brute force burst.
How do I block RDP brute force attackers automatically?
Use a PowerShell script with New-NetFirewallRule to add inbound block rules for attacking IPs on port 3389. Run the script as a scheduled task that processes a blocked-IPs list generated by your SIEM correlation rule. Log each block as a custom Windows Security event for audit tracking. Review and expire blocks monthly to handle legitimate IPs that were temporarily compromised or NATed.
Should RDP be exposed directly to the internet?
No. RDP (port 3389) should never be directly exposed to the internet. Ransomware groups and commodity attackers continuously scan for open RDP — a system with RDP exposed typically receives thousands of login attempts per day. Proper RDP access architecture: require VPN before RDP is reachable (VPN provides a first authentication layer and narrows the attack surface to VPN clients only); or use a Remote Desktop Gateway (RDG) that requires certificate authentication before proxying RDP sessions; or use Azure Bastion or AWS Session Manager for cloud workloads (browser-based access with no open RDP port). Monitor your internet-facing attack surface with Shodan or Censys periodic scans to detect accidentally exposed RDP on any hosts in your IP ranges.
What is RDP Network Level Authentication (NLA) and why does it matter?
Network Level Authentication (NLA) requires the client to authenticate (username and password) before the Remote Desktop session is established, rather than after. Without NLA, the Windows login screen is presented to an unauthenticated attacker — creating exposure to credential brute force directly against the desktop session. With NLA, unauthenticated users never reach the desktop — they must provide valid credentials to NTLM or Kerberos at the network layer first. Enable NLA via Group Policy: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > RDP Session Host > Security > Require NLA for remote connections = Enabled. NLA also mitigates some BlueKeep (CVE-2019-0708) variants by requiring authentication before the vulnerable RDP component is reached.
How do I detect successful RDP lateral movement in event logs?
Successful RDP lateral movement leaves multiple events: on the source machine, Event ID 4648 (logon using explicit credentials) when the attacker uses a different account for the RDP connection; on the destination machine, Event ID 4624 Logon Type 10 (RemoteInteractive) with the attacker's source IP; and Event ID 1149 in the Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational log which records the source IP and username for every successful RDP connection. Build an alert: any workstation receiving an RDP connection (4624 Logon Type 10) from another workstation IP (not a server or admin system IP range) is strong lateral movement signal — workstation-to-workstation RDP is rare in normal operations.
How do you tune RDP brute force detection thresholds to reduce false positives from legitimate helpdesk and admin activity?
Threshold tuning for RDP brute force detection requires baselining legitimate failure patterns before setting alert thresholds. Run the detection query in passive mode for two weeks and review which source IPs and accounts generate the highest legitimate failure counts: helpdesk jump servers, password reset tools, and backup agents often generate clusters of 5-15 failures during scheduled credential rotation. Create a named watchlist or allowlist in your SIEM for these known-good source IPs and exclude them from the threshold-based alert while still logging their events for anomaly review. Apply different thresholds by source classification: alert on 5 failures per 5 minutes from external internet IPs (where any RDP is suspect), 30 failures per 5 minutes from internal corporate IP ranges, and 10 failures per 5 minutes from internal IPs targeting domain controllers (where legitimate RDP should be rare). Add a velocity dimension to catch slow-and-low attacks: alert when a single source IP generates more than 200 failures over 24 hours even if it stays below the 5-minute threshold, since attackers increasingly throttle attempts to evade rate-based rules.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.