3389: The Port That Keeps Giving — to Attackers
In 2023, the FBI's Internet Crime Complaint Center flagged Remote Desktop Protocol (RDP) as the single most common initial access vector in ransomware incidents reported to law enforcement. Not phishing. Not USB drives. RDP. And yet, in 2026, I still find organizations with port 3389 wide open to the internet, protected by nothing more than a four-character password and hope.
If you run any flavor of remote desktop — Microsoft RDP, third-party remote access tools, or VDI — you need to understand the remote desktop security risks that threat actors actively exploit every single day. This post breaks down exactly how attackers get in, what they do once inside, and the concrete steps that actually reduce your exposure.
Why Attackers Love Remote Desktop Protocol
RDP was designed for convenience. An admin needs to troubleshoot a server at 2 AM? Remote in. An employee needs their desktop from home? Fire up RDP. That convenience is precisely what makes it dangerous.
Here's what actually happens. Threat actors use tools like Shodan and Masscan to sweep the entire IPv4 address space looking for exposed RDP endpoints. A 2024 scan by the Shadowserver Foundation found over 3.6 million RDP services publicly reachable. Each one of those is a door waiting to be kicked in.
Once they find an exposed endpoint, attackers launch brute-force or credential-stuffing attacks using credentials harvested from previous data breaches. They don't need zero-days. They don't need sophisticated malware. They just need your employee's reused password from the 2021 LinkedIn breach.
The Brute-Force Assembly Line
Automated tools cycle through millions of username-password combinations per hour against exposed RDP endpoints. I've reviewed incident logs where a single IP address attempted over 100,000 login combinations in a 24-hour window — against a small business with twelve employees.
Without account lockout policies, rate limiting, or multi-factor authentication, it's just a matter of time before one combination lands. Once an attacker has a valid session, they're inside your network with the same privileges as the compromised user.
The Real-World Damage: What Happens After the Breach
Let's stop talking in hypotheticals. The Verizon 2024 Data Breach Investigations Report found that stolen credentials were involved in roughly 77% of attacks against web applications and remote access services. RDP-based intrusions frequently lead to three outcomes, and none of them are good.
Ransomware Deployment
Groups like LockBit and Akira have historically used compromised RDP sessions as their primary foothold. Once inside, they disable security tools, move laterally using tools like PsExec or Cobalt Strike, and deploy ransomware across every reachable system. The median cost of a ransomware attack hit $4.88 million in IBM's 2024 Cost of a Data Breach Report.
Data Exfiltration and Extortion
Before encrypting anything, many threat actors now exfiltrate sensitive data. They'll spend days or weeks quietly copying financial records, customer databases, and intellectual property. Then comes the double extortion: pay to decrypt, and pay again to keep your data off their leak site.
Persistent Backdoors
Sophisticated attackers don't just smash and grab. They install persistent access — new user accounts, scheduled tasks, web shells — so they can return even after you think you've cleaned up. I've worked incidents where the attacker maintained access for over six months before anyone noticed.
What Are the Biggest Remote Desktop Security Risks?
If you're searching for a clear breakdown, here it is. These are the specific remote desktop security risks that I see exploited most frequently:
- Exposed RDP ports: Port 3389 open to the internet with no VPN or gateway in front of it.
- Weak or reused credentials: Passwords sourced from previous data breaches or easily guessable combinations.
- No multi-factor authentication: Single-factor RDP access is an open invitation for credential theft attacks.
- Unpatched systems: Known RDP vulnerabilities like BlueKeep (CVE-2019-0708) still exist on internet-facing systems years after patches were released.
- Excessive user privileges: Users connecting via RDP with local admin rights give attackers immediate escalation paths.
- No network segmentation: Once inside via RDP, attackers can reach everything — file servers, domain controllers, databases.
- Disabled logging or monitoring: If nobody reviews RDP authentication logs, nobody sees the brute-force attempts until it's too late.
How to Lock Down Remote Desktop Access
You don't have to stop using remote desktop entirely. You do have to stop using it carelessly. Here's what works.
Never Expose RDP Directly to the Internet
This is non-negotiable. Place RDP behind a VPN or a Remote Desktop Gateway. If your users need remote access, they authenticate to the VPN first, then connect to RDP inside your network. CISA's guidance on securing remote access is explicit about this.
Enforce Multi-Factor Authentication Everywhere
MFA on VPN access. MFA on RDP gateway authentication. MFA on privileged accounts. This single control stops the overwhelming majority of credential-stuffing attacks dead. If an attacker has a stolen password but not the second factor, they're locked out.
Implement Network Level Authentication (NLA)
NLA requires users to authenticate before the RDP session is fully established. This reduces the attack surface by preventing unauthenticated users from even reaching the login screen, which blocks several classes of denial-of-service and pre-authentication exploits.
Patch Aggressively
BlueKeep made headlines in 2019 because it was wormable — no user interaction required. Microsoft patched it immediately. And yet, years later, security researchers still find unpatched systems vulnerable to it. Your patching cadence for remote access infrastructure should be measured in days, not months. The NIST National Vulnerability Database is your reference for tracking known RDP-related CVEs.
Apply the Principle of Least Privilege
No user should RDP into a system with local administrator rights unless absolutely necessary. Create dedicated remote access accounts with limited permissions. If an account gets compromised, restricted privileges dramatically limit the blast radius.
Enable and Monitor Logging
Windows Event IDs 4624, 4625, and 4648 tell you who's logging in, who's failing to log in, and who's using alternate credentials. Feed these into a SIEM or at minimum review them weekly. You can't defend what you can't see.
Zero Trust: The Framework That Fixes This
Every control I just described fits within a zero trust architecture. Zero trust assumes that no user, device, or network segment should be inherently trusted. Every access request gets verified. Every session gets evaluated.
For remote desktop specifically, zero trust means: verify the user's identity (MFA), verify the device's health (endpoint compliance checks), limit the session's network access (microsegmentation), and monitor continuously for anomalous behavior. It's not a product you buy. It's a way of designing your access controls.
Your People Are Part of the Problem — and the Fix
Technical controls matter. But your employees are the ones choosing weak passwords, clicking phishing links that harvest their RDP credentials, and ignoring security warnings. Social engineering remains the most effective way for attackers to obtain the credentials they use in RDP attacks.
This is where cybersecurity awareness training changes the equation. When your team understands how credential theft works, they stop reusing passwords and start reporting suspicious login prompts.
Pair that with phishing awareness training for your organization and you address the social engineering pipeline that feeds RDP compromise. Phishing simulations teach employees to recognize the fake Microsoft login pages and credential-harvesting emails that directly lead to stolen RDP access.
The Audit Checklist You Can Use Today
Run through this list right now. If you can't answer "yes" to every item, you have work to do:
- Have you scanned your external IP ranges for exposed port 3389?
- Is all RDP access routed through a VPN or gateway?
- Is MFA enforced on every remote access pathway?
- Are RDP-capable systems patched within 48 hours of critical CVE disclosure?
- Do you have account lockout policies set for failed login attempts?
- Are RDP session logs actively monitored and alerted on?
- Have your employees completed security awareness training in the last 90 days?
Every "no" on that list is a gap a threat actor can exploit. The FBI IC3's annual reports consistently show that basic hygiene failures — not sophisticated zero-days — cause the majority of reported cyber incidents.
Stop Treating RDP Like a Convenience Feature
Remote desktop is infrastructure. Critical infrastructure. It deserves the same level of hardening you'd apply to your firewall or your domain controller. The remote desktop security risks I've described aren't theoretical — they're being actively exploited right now against organizations of every size.
Lock down the port. Enforce MFA. Patch relentlessly. Train your people. And stop assuming that because RDP is built into Windows, it's safe by default. It's not. It never was.