RDP Security: Why Exposed RDP is the #1 Ransomware Entry Point

Why RDP is the most dangerous exposed port

Remote Desktop Protocol (RDP) on port 3389 is consistently the number one entry point for ransomware attacks. Security researchers and incident response firms report that a significant share of ransomware incidents begin with an attacker gaining access through an exposed RDP endpoint.

The reasons are straightforward:

RDP gives full graphical desktop access -- once in, attackers can do everything a legitimate user can
It uses username/password by default -- vulnerable to brute force and credential stuffing
It has had critical vulnerabilities -- BlueKeep (CVE-2019-0708) and others allow remote code execution without authentication
Automated scanners find it instantly -- tools like Shodan and Masscan index every RDP server on the internet
Stolen credentials are cheap -- RDP access is sold on criminal marketplaces for as little as a few dollars per endpoint

Real-world attack scenarios

Brute force

Attackers use tools like Hydra or NLBrute to try thousands of username/password combinations against your RDP server. Common targets include Administrator, admin, user, and any usernames leaked in previous breaches.

Credential stuffing

Attackers take credentials from other breaches (LinkedIn, Dropbox, etc.) and try them against your RDP. If any employee reused a password, the attacker gets in.

CVE-2019-0708 (BlueKeep) allows an attacker to execute code on a vulnerable Windows system without any authentication. While patched in May 2019, unpatched systems are still found on the internet. Similar vulnerabilities (DejaBlue -- CVE-2019-1181/1182) affect newer Windows versions.

Credential marketplace

Cybercriminals scan the internet for RDP servers, brute force credentials, and then sell access on dark web marketplaces. Ransomware operators buy this access and deploy their payload.

Never expose RDP directly to the internet

This is not a recommendation -- it is a rule. There is no configuration of RDP that makes it safe to expose directly to the public internet. Even with:

Network Level Authentication (NLA) enabled
Strong passwords
Account lockout policies
The latest patches

The risk remains unacceptably high. Zero-day vulnerabilities, credential leaks, and the sheer volume of automated attacks mean that direct RDP exposure is a matter of "when," not "if."

Secure alternatives to direct RDP

Option 1: VPN then RDP

The most common approach. Users connect to a VPN first, then RDP to internal systems over the private network.

User --> VPN (WireGuard/OpenVPN) --> Private Network --> RDP to Server

Implementation:

Set up a VPN server (WireGuard is recommended for performance and simplicity)
Block port 3389 from the internet at the firewall level
Allow RDP only from the VPN subnet

# Windows Firewall: Allow RDP only from VPN subnet
New-NetFirewallRule -DisplayName "RDP from VPN only" -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress 10.0.0.0/24 -Action Allow

# Block RDP from everywhere else
New-NetFirewallRule -DisplayName "Block RDP public" -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Block

Option 2: RD Gateway

Remote Desktop Gateway (RD Gateway) is a Windows Server role that proxies RDP connections over HTTPS (port 443). Users connect to the gateway, which authenticates them and then forwards the RDP session to the target server.

Benefits:

RDP traffic is wrapped in TLS on port 443
Supports multi-factor authentication
Centralised access logging and policies
No direct RDP exposure to the internet

Option 3: Azure Bastion

If your servers are in Azure, Azure Bastion provides browser-based RDP and SSH access without any public IP on the target VM. Sessions run through the Azure portal over HTTPS.

Option 4: Jump server (bastion host)

Similar to the SSH bastion host approach, place a single hardened Windows server as the entry point. Users RDP to the jump server, then RDP from the jump server to internal systems.

The jump server should:

Be fully patched at all times
Require MFA for login
Have enhanced logging and monitoring
Be the only system with RDP accessible from outside (via VPN, ideally)

How to check if RDP is exposed

Using nmap

# Check if port 3389 is open on your public IP
nmap -p 3389 your-public-ip

# Scan a range for exposed RDP
nmap -p 3389 --open your-ip-range/24

Using Shodan

Search Shodan for your IP range:

port:3389 net:your-ip-range/24

If Shodan shows results, your RDP is visible to the entire internet -- and to every attacker scanning it.

From the server itself

# Check if RDP is listening on all interfaces
netstat -an | findstr ":3389"

# If it shows 0.0.0.0:3389 LISTENING, RDP is accessible on all network interfaces

Emergency steps if RDP is currently exposed

If you have just discovered that RDP is exposed to the internet, act immediately:

1. Block port 3389 at the firewall NOW

# Linux firewall (if the server is behind a Linux gateway)
sudo iptables -A INPUT -p tcp --dport 3389 -j DROP

# Or in your cloud provider's security group:
# Remove the rule allowing inbound TCP 3389 from 0.0.0.0/0

# Windows Firewall
New-NetFirewallRule -DisplayName "Emergency: Block RDP" -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Block

2. Check for unauthorized access

# Review recent RDP logins in Windows Event Log
# Event ID 4624 (successful logon) with Logon Type 10 (RemoteInteractive)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} |
  Where-Object { $_.Properties[8].Value -eq 10 } |
  Select-Object TimeCreated, @{N='User';E={$_.Properties[5].Value}}, @{N='SourceIP';E={$_.Properties[18].Value}} |
  Sort-Object TimeCreated -Descending | Select-Object -First 20

Look for logins from unexpected IP addresses, at unusual times, or from unfamiliar user accounts.

3. Change all passwords

If there is any sign of unauthorized access, change all local and domain admin passwords immediately.

4. Check for malware

Run a full antimalware scan. Look for:

New user accounts that should not exist
Scheduled tasks you did not create
Unusual processes or services
Ransomware notes or encrypted files

5. Patch the system

Ensure all Windows updates are applied, especially:

CVE-2019-0708 (BlueKeep)
CVE-2019-1181 and CVE-2019-1182 (DejaBlue)
Any recent RDP-related security updates

6. Set up a secure alternative

Before re-enabling remote access, implement one of the secure alternatives described above (VPN, RD Gateway, or bastion host).

RDP hardening checklist (for the access method you choose)

Even when RDP is behind a VPN or gateway, apply these settings:

Network Level Authentication (NLA) enabled
Account lockout policy configured (e.g., lock after 5 failed attempts)
RDP restricted to specific user group (do not leave "Everyone" in Remote Desktop Users)
TLS encryption enforced for RDP connections (not the legacy RDP encryption)
Session timeout configured for idle sessions
RDP event logging enabled and monitored
Multi-factor authentication in place (via RD Gateway or third-party)
All systems fully patched

Review our guide on open ports security for other services that should never be directly exposed, and securing SSH access for the Linux equivalent.

How SurfaceScan helps

SurfaceScan scans your entire external attack surface for exposed RDP services -- on port 3389 and on non-standard ports where RDP is sometimes moved to. An exposed RDP finding is flagged as critical severity because of the direct ransomware risk. SurfaceScan also detects related risks like other exposed management interfaces (SSH, VNC, Telnet) and dangerous open ports. Each finding includes the IP address, port, and guidance on how to secure it, so your team can act immediately.