Remote Desktop Protocol has been around since 1998. In that time, the security industry has produced hundreds of advisories, patches, emergency directives, and post-mortems about it. And yet, in 2024, RDP remains one of the most reliably exploited services on the internet.<\/p>\n
According to the FBI’s Internet Crime Complaint Center, ransomware attacks cost U.S. organizations more than $59.6 million in reported losses in 2023 alone \u2014 and independent research consistently identifies RDP as the leading initial access vector for ransomware deployments, appearing in over 50% of confirmed incidents analyzed by incident response firms. The attack surface hasn’t shrunk. If anything, the hybrid work shift between 2020 and 2022 pushed organizations to expose RDP more aggressively than ever \u2014 and many never pulled it back.<\/p>\n
This article is about why that gap still exists, what attackers actually do with it, and what a realistic fix looks like in a typical Windows environment.<\/p>\n
RDP attacks are rarely sophisticated. That’s what makes them durable.<\/p>\n
Brute force and credential stuffing are the entry-level techniques. Port 3389 \u2014 the default RDP port \u2014 is scanned globally within minutes of any new IP being allocated. Tools like Shodan and Censys index millions of exposed RDP endpoints, and threat actors use automated tools to fire credential lists against them continuously. A network with 200 users has statistically predictable passwords: company name + year, first name + birthdate, Welcome1, Summer2024. It takes modest computing resources to cycle through these.<\/p>\n
Pass-the-hash moves the attack one level up. Once an attacker has obtained an NTLM hash from one system \u2014 through a phishing payload, a compromised endpoint, or a leaked database \u2014 they don’t need to crack it. Windows authentication accepts the hash directly. An attacker who compromises a low-privilege workstation can harvest hashes from memory using tools like Mimikatz, then authenticate via RDP to higher-value servers without ever knowing the plaintext password.<\/p>\n
BlueKeep (CVE-2019-0708) served as a wake-up call about how catastrophic unpatched RDP can be. A pre-authentication remote code execution vulnerability in Windows 7, XP, and Server 2008, it allowed an attacker to compromise a machine without credentials at all. Microsoft issued an emergency patch and CISA issued an emergency directive \u2014 and yet months after the patch, hundreds of thousands of vulnerable systems remained reachable on the public internet.<\/p>\n
Man-in-the-middle attacks exploit the fact that many RDP deployments skip Network Level Authentication (NLA) or use self-signed certificates that clients blindly accept. An attacker positioned between the client and server can capture credentials in transit. In environments where certificate validation warnings are routinely clicked through by users, this is a practical attack, not a theoretical one.<\/p>\n
The pattern across all these techniques: they work because the authentication step is a single gate, and that gate is a password. Passwords leak, get reused, get phished, get cracked, and get stolen from memory. The gate holds until it doesn’t.<\/p>\n
The standard IT response to exposed RDP is to restrict it: put it behind a VPN, add IP allowlisting, or both. These are worthwhile controls. They are not sufficient on their own.<\/p>\n
VPN-gated RDP reduces the exposure surface, but it moves the problem rather than eliminating it. The VPN itself becomes the target. VPN credentials face the same brute force, phishing, and credential stuffing attacks as RDP did before. Once inside the VPN, attackers often find internal RDP services with no additional authentication required \u2014 a single compromised VPN credential opens the entire internal network.<\/p>\n
IP allowlisting assumes a stable set of source addresses. For a fully managed corporate fleet, this is plausible. For any organization with remote workers, contractors, or traveling employees, it creates operational friction that drives users to request exceptions \u2014 and exceptions accumulate into gaps.<\/p>\n
Jump hosts and RD Gateways add an architectural layer, but they don’t add a second factor. A compromised set of credentials still authenticates to the gateway.<\/p>\n
None of these controls addresses the core problem: the authentication decision is made on the basis of a single shared secret, and shared secrets fail.<\/p>\n
The cybersecurity standards community reached consensus on this years ago.<\/p>\n
NIST Special Publication 800-63B defines Authenticator Assurance Level 2 (AAL2) \u2014 the baseline for access to any sensitive system \u2014 as requiring two distinct authentication factors. Password-only authentication satisfies no assurance level in the current NIST framework; it doesn’t even reach AAL1 for high-value targets.<\/p>\n
CISA’s guidance on remote access security explicitly lists MFA as a required control for any remote desktop or remote access service exposed to employees or contractors. Their Known Exploited Vulnerabilities catalog contains dozens of RDP-related entries, and their advisory on ransomware prevention consistently names “enable MFA on all remote access” as the highest-priority mitigation.<\/p>\n
PCI DSS v4.0 (Requirement 8.4.2) mandates MFA for all remote access to the cardholder data environment, whether by employees or vendors. HIPAA’s technical safeguards require access controls and authentication mechanisms that would be satisfied by MFA. The EU NIS2 Directive (Article 21) explicitly requires multi-factor or continuous authentication for access to network and information systems for essential and important entities.<\/p>\n
The standards aren’t suggesting MFA for RDP as a best practice. They’re treating it as a baseline requirement.<\/p>\n
The main objection IT teams raise about RDP MFA is operational friction. Users already struggle with the RDP connection flow; adding a second step sounds like a support ticket generator.<\/p>\n
In practice, when it’s implemented at the Windows Credential Provider level \u2014 meaning the second factor is requested as part of the normal Windows login screen, not bolted on as a separate web step \u2014 users adapt quickly. The flow becomes: enter username and password, enter a six-digit TOTP code from an authenticator app. Most users find this takes under ten seconds once they’re enrolled.<\/p>\n
The enrollment process is the more sensitive part. Self-service enrollment portals (where users scan a QR code to register their authenticator app) have a much higher completion rate than IT-driven enrollment. Sending a link via email with a deadline attached, combined with a brief internal FAQ, typically gets 90%+ enrollment within a week for organizations under 500 users.<\/p>\n
Hardware token options exist for users who can’t or won’t use a smartphone: small TOTP devices that generate codes the same way an authenticator app does, but with no internet connection or battery dependency beyond the token itself. These are useful for operations staff, warehouse environments, or any role where phone use is restricted.<\/p>\n