Discover how 260 exposed RDP servers expose attackers to brute-force and ransomware. Learn how NLA, VPN, and custom password lists protect against RDP attacks.

RDP: I Found 260 Exposed Servers – How NLA, Brute-Force, and Defense Stack Up

Published by Brav

TL;DR

• 260 servers on port† 3389 were exposed to the internet in a single scan.
• NLA is the frontline guard; disabling it opens the door to brute‑force and ransomware attacks.
• Custom password lists and VPN/IP‑whitelisting can shrink brute‑force windows from days to hours.
• Capture RDP screenshots to learn OS build, banner, and NLA status before you hit the target.
• Use Shodan for reconnaissance, Wireshark for traffic analysis, and ncrack for credential testing.

Why this matters

I used to run a small penetration‑testing firm in the mid–2000s, when RDP was a staple for remote administration. Back then, a single misconfigured port could be a gateway for a full‑blown compromise. The same risk lives today, but the numbers are even higher.

RDP servers exposed on the public internet are common Shodan — Shodan (2025). Even a single active service can turn your lab into a playground for attackers. In my recent lab, I discovered 260 hosts that accepted RDP connections without any VPN or IP whitelisting in place. Those systems were running Windows Server 2000, 2008, 2012, and 2016† 1607 — all older builds that still have known CVEs in the public database CVE — NVD (2025).

The biggest threat factor is Network Level Authentication (NLA) being turned off NLA — NLA (2025). When NLA is disabled, a brute‑force attempt has to start the full RDP handshake, which is slow and noisy. Attackers can use a large dictionary — I once used a 14‑million‑entry list called “brock† q† dot† txt” — and it took days to hit a valid credential SecLists — Password List Repository (2025).

Without a VPN or IP whitelisting, anyone who can reach port† 3389 can try to guess passwords, and if they get lucky, they can elevate privileges and run ransomware. The lesson: every exposed RDP server is a potential launchpad for malicious actors, and the lack of basic defenses creates a low‑barrier path to compromise.

Core concepts

RDP and port† 3389

Remote Desktop Protocol (RDP) is a proprietary Microsoft protocol that allows you to control a Windows machine from anywhere. By default, it listens on TCP† 3389, so a quick scan for that port reveals potential RDP services Shodan — Shodan (2025).

Showdown scanning and screenshots

I use a custom tool called Showdown in my lab. It connects to every host that responds on port† 3389, pulls the login screen without needing credentials, and saves the image. The screenshot shows the Windows build number and any custom banner you might have set. Even if you don’t have a user name, the banner can tell you if the target is Windows Server‖2016† 1607 or an older 2008 build.

NLA — the first line of defense

Network Level Authentication requires the client to present credentials before a full RDP session starts. If NLA is enabled, an attacker must supply a correct password before the handshake completes. NLA is a simple but powerful filter; disabling it turns the door open to brute‑force or credential‑spraying attacks NLA — NLA (2025).

You can enable or disable NLA on a Windows Server from Control Panel → System → Remote → Remote Desktop → Advanced Settings, or via PowerShell:

Set-ItemProperty -Path "HKLM:\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server" -Name fDenyTSConnections -Value 0

When fDenyTSConnections is set to 0, RDP is active, and if you also set UserAuthentication to 0, NLA is disabled.

Brute‑force vs. password spraying

A brute‑force attack tries many passwords against a single account. A password‑spraying attack tries a small set of common passwords across many accounts. With RDP, brute‑force is slow because every attempt initiates the full RDP handshake. Even on a fast LAN, a 14‑million‑entry list can take several days. A custom list — like the one I created from leaked credentials — can reduce the attack surface dramatically.

RDP handshake and banner grabbing

When you first connect to an RDP service, the server sends a banner that includes the OS version, build number, and any custom login message. Tools like Wireshark can capture this handshake. Applying a filter like tcp.port == 3389 or frame contains “Remote Desktop” shows the raw RDP packets and lets you verify whether NLA is required Wireshark — Wireshark (2025).

CVE database and targeted exploitation

The National Vulnerability Database (NVD) catalogs every known vulnerability for each Windows Server build. Once I know a target is running 2016† 1607, I pull the CVE list and look for zero‑day or unpatched bugs. An example is CVE‒ 2019‒ 0688, which allows a malicious RDP client to execute code with system privileges if NLA is disabled CVE — NVD (2025).

How to apply it

Below is a practical walk‑through that turns reconnaissance into an attack chain. I ran this in a controlled lab using Kali Linux, Showdown, Wireshark, and ncrack. Follow these steps to replicate the process, or adapt it for real‑world engagement.

1. Discover open RDP hosts
   Use Shodan or Showdown to scan the internet for hosts listening on port† 3389.

   shodan search port:3389 has_screenshot:true -f csv > rdp_hosts.csv
   

   This command pulls a CSV file with IPs, country, organization, and screenshot URLs. In my lab, the scan returned 260 distinct IPs Shodan — Shodan (2025).

2. Grab the login screen
   Showdown automatically pulls a screenshot for each host. If you want to do it manually, use the Windows Remote Desktop Client to connect and capture the screen using the built‑in “Print Screen” key or a tool like Snagit. The screenshot reveals the OS build and any custom banner that could hint at the server role.

3. Determine NLA status
   Try a simple RDP connection from a Kali box. If you land on the login screen without being prompted for credentials, NLA is disabled. I used a script that attempts a blank password and logs whether the handshake completes or stalls.

4. Filter traffic with Wireshark
   Capture the RDP handshake while attempting a connection. Apply the filter tcp.port == 3389. Look for the “Remote Desktop Protocol” handshake packets. If you see a “TS Request” packet, NLA is likely off. If you see a “TSA” packet asking for credentials, NLA is on.

5. Prepare a custom password list
   Download a large password list from SecLists or build your own from leaked credentials. In the lab, I used the “brock† q† dot† txt” list — 14‑million‑entries — and trimmed it to the top 100,000 most common passwords. Store the list in a file called passlist.txt.

6. Run ncrack for credential testing

   ncrack -p 3389 -U userlist.txt -P passlist.txt -T4 -w 1 <target_ip>
   

   The -T4 flag increases concurrency, and -w 1 keeps the timeout short to avoid long pauses. In my test, the correct credentials were found after 4‑hours — a fraction of the days it would have taken with the full 14‑million list Ncrack — Ncrack (2025).

7. Leverage CVE exploits
   Once you have access, search the NVD for vulnerabilities specific to the Windows build you discovered. If CVE‒ 2019‒ 0688 is available, download an exploit from the Exploit‑DB repository and run it with the user privileges you just gained.

8. Pivot to privilege escalation
   Use built‑in Windows tools like net localgroup administrators to check if you’re part of the admin group. If not, use the “psexec” or “winrm” modules from Metasploit to elevate.

9. Maintain persistence
   Drop a scheduled task or install a backdoor (e.g., a malicious DLL) to keep access if you need to come back later. Always document each step for a clean report.

Metrics that matter

• Number of hosts: 260 RDP servers found on the internet.
• Password list size: 14‑million entries — reduces to 100,000 after trimming.
• Time to compromise: 4‑hours with a trimmed list, versus days with the full list.
• CVE count for 2016† 1607: 12 known critical CVEs that can be leveraged if NLA is off.

These metrics show the tangible impact of securing RDP: a few minutes of effort can eliminate days of brute‑force.

Pitfalls — edge cases

I’ve spent years testing RDP, and a few recurring mistakes keep popping up.

• Assuming NLA is always on — Many administrators forget that legacy clients or misconfigurations can turn it off NLA — NLA (2025).
• Relying on default usernames — The default admin account is often named “Administrator”, which is the first target.
• Using a single massive dictionary — A 14‑million‑entry list is great for breadth, but it’s also a waste of time on a slow RDP server. Trimming the list to the most frequent passwords reduces the attack surface SecLists — Password List Repository (2025).
• Ignoring rate limiting — Some servers lock the account after a few failed attempts. If you hit a lockout, pause and use a different credential or a password‑spraying technique.
• Assuming CVEs are present — Just because a server is running 2016† 1607 doesn’t mean it’s still vulnerable. Check the host’s patch level via the Windows Update service or a third‑party patch‑management tool before you launch an exploit CVE — NVD (2025).
• Skipping VPN/IP whitelisting — Even if you’ve nailed the credentials, an exposed RDP port is still reachable by anyone. If you’re in a penetration‑testing engagement, always tunnel the traffic through a VPN or restrict by IP. A mis‑configured firewall can leave the door open.
• Overlooking banner grabbing — Some organizations hide their OS version or display a generic “Welcome” message. In those cases, you’ll need to rely on other reconnaissance methods, such as SMB enumeration or a port scan for other open services that might reveal the build number.

These pitfalls underline that securing RDP is not just a matter of a single setting. It’s a layered approach: proper authentication, network isolation, patch management, and continuous monitoring.

Quick FAQ

1. How does Showdown capture screenshots of remote login screens?
   Showdown opens an RDP session to the target and intercepts the graphical stream before authentication. The client saves the first frame, which contains the login banner.

2. What is the process to filter RDP traffic in Wireshark?
   Set the display filter tcp.port == 3389 or frame contains ‘Remote Desktop’. Then examine the handshake packets to see if NLA is requested.

3. How can NLA be enabled or disabled in Windows Server?
   Use the GUI: Control Panel → System → Remote → Remote Desktop → Advanced Settings → check or uncheck “Allow connections only from computers running Remote Desktop with Network Level Authentication.” Or use PowerShell: Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server’ -Name UserAuthentication -Value 1.

4. What specific vulnerabilities are listed for Windows Server† 2016 version† 1607?
   The NVD lists CVE‒ 2019‒ 0688 (remote code execution), CVE‒ 2018‒ 0883 (buffer overflow), and others. Search “Windows Server 2016 1607 CVE” on the NVD portal.

5. Why does RDP brute force take days with a 14‑million password list?
   Each attempt triggers a full RDP handshake, which involves multiple round-trips and cryptographic operations. Network latency and server rate limiting add further delays. A custom, smaller list speeds up the process.

6. What are the best practices to mitigate exposed RDP servers?

   • Enable NLA.
   • Enforce VPN or IP whitelisting.
   • Use MFA wherever possible.
   • Keep systems patched against known CVEs.
   • Set a strong password policy and avoid default accounts.

7. How can I quickly identify if a target server has NLA disabled?
   Connect with an RDP client using a blank password. If the client lands on the login screen without being prompted for credentials, NLA is disabled.

Conclusion

When I first started hacking RDP, I thought a simple password check was enough. Today, the reality is that an exposed RDP server is a high-risk asset, and the cost of leaving it open is high. By combining reconnaissance (Shodan or Showdown), visual verification (screenshots), credential testing (ncrack), and exploit research (CVE database), I can move from a passive scan to an active compromise in a few hours.

If you’re a system administrator, the takeaway is simple: lock down every RDP instance. Turn on NLA, enforce a VPN or IP whitelist, enable MFA, and keep your Windows Server patch cycle current.
If you’re a red-team or penetration tester, use the workflow above to validate your client’s security posture quickly and reproducibly.

I’ve seen the same pattern repeat in corporate networks, government agencies, and even home labs. Stop treating RDP as a “nice-to-have” feature and start treating it as a critical attack surface that demands rigorous defense.

Glossary

• Remote Desktop Protocol (RDP) — Microsoft’s protocol for remote control of Windows machines over a network.
• Port† 3389 — The default TCP port used by RDP.
• Network Level Authentication (NLA) — A security feature that authenticates the client before a full RDP session begins.
• VPN (Virtual Private Network) — Encrypts traffic between the client and server, providing a secure tunnel.
• MFA (Multi-Factor Authentication) — Requires more than one credential factor to log in.
• IP Whitelisting — Restricts access to a list of approved IP addresses.
• CVE (Common Vulnerabilities and Exposures) — Public database of known software vulnerabilities.
• Brute‑Force — Trying many passwords or usernames until the correct one is found.
• Password Spraying — Attempting a small set of common passwords against many accounts.
• Screenshot — Capturing the login screen before authentication.
• Banner Grabbing — Retrieving service banner data to identify software and version.
• RDP Handshake — The initial protocol exchange that establishes a session.
• RDP Server — A machine running the Remote Desktop Service.
• RDP Vulnerability — A flaw that can be exploited through RDP.
• Remote Desktop Exploitation — Using RDP vulnerabilities to gain unauthorized access.