Five years after the IT industry pronounced RDP “solved,” Remote Desktop Protocol is still the single most-abused initial-access vector for ransomware operators. Coveware’s incident-response telemetry attributed roughly half of all 2025 ransomware incidents to RDP-related compromise, broker-sold credentials, weak passwords, exposed RDS gateways, and recurring patch-management failures around protocol-level CVEs. The 2026 picture so far looks identical. RDP is not getting better. The attackers are getting more efficient.
This is a practitioner’s walkthrough of what actually compromises RDP environments in 2026, with the controls and detection signals that move the needle. Written for SOC analysts, IT teams running mid-market estates, and security-aware founders who want to know what to push their IT lead to fix this quarter.
The five RDP attack patterns that dominate 2026
1. Stolen credentials from stealer logs and initial-access brokers
The dominant pattern. An employee opens a malicious installer at home on a personal device, the infostealer harvests every credential in their Chrome / Edge profile, including the corporate RDP gateway URL and the saved username and password, and the entire bundle ends up in a Telegram-distributed log within hours. Hours-to-days later, the credential surfaces in an initial-access-broker listing, gets bought for between $200 and $5,000 depending on company size, and the buyer authenticates against your RDP exactly as the real user would.
From your logs, this looks like a successful login from an unusual IP at a strange hour. No brute force. No exploit. No alert. By the time anyone notices, ransomware has been staged. This is the threat model that the Stealercheck domain-exposure tool is built around, and it’s why we keep saying that stealer logs are the modern attack surface that traditional MFA does not cover.
2. Credential stuffing and brute force
Less elegant, still effective. Automated tools spray recycled breach passwords against exposed RDP endpoints at scale. Even a 0.1% success rate is profitable when the candidate set is millions of accounts. The defenders that get burned here are the ones who think “we have a strong password policy” without realising that a user’s password from a 2018 LinkedIn breach is just as good against today’s RDP login as one captured yesterday, because most users rotate passwords by adding a digit, not by changing them.
3. Exposed Remote Desktop Services / Gateway misconfigurations
Open Shodan right now and search for port:3389 country:us. You’ll find tens of thousands of corporate RDP endpoints reachable directly from the internet, often with Network Level Authentication disabled or with the certificate misconfigured in a way that lets man-in-the-middle attacks succeed. The dominant misconfig in 2025–2026: organisations that stood up a Remote Desktop Gateway for COVID-era remote work and then never reviewed which endpoints it was actually publishing.
4. Insider and departed-employee credentials
A frighteningly common 2026 pattern. An employee leaves, the offboarding process forgets the RDP user account because it was set up out-of-band years earlier, and either the former employee or someone who buys their credentials uses the still-active account to access the network. This is the category most often missed by traditional vulnerability management because there’s no vulnerability, the system is working exactly as configured.
5. Protocol-level CVE exploitation
The smallest slice but the most dramatic. BlueKeep (CVE-2019-0708) is six years old and still finds unpatched Windows Server 2012 R2 instances in 2026. More recent: CVE-2024-38077 (Windows Remote Desktop Licensing Service RCE), patched in 2024, but unpatched estates exist. The pattern when these land is always the same: a known fix has existed for months, the patch-management gap is the actual root cause, not the CVE.
Why the obvious advice (“turn off RDP”) doesn’t work
The single most common piece of “expert” guidance is “don’t expose RDP to the internet.” It’s correct, it’s been correct for fifteen years, and it’s failed to change the data because operationally, organisations need remote administration. The choice in 2026 is not whether to remove RDP, it’s how to wrap it so the five attack patterns above don’t land.
Controls that actually move the needle
- Front the RDP gateway with phishing-resistant MFA. Hardware FIDO2 keys, Windows Hello for Business, or platform-attested passkeys. SMS and TOTP are not enough in 2026, adversary-in-the-middle phishing kits ([Evilginx, Modlishka](https://github.com/drk1wi/Modlishka)) defeat them routinely. The single biggest reduction-in-exposure control we observe in IR cases is “did the org have FIDO2 in front of RDP?”, yes = the credential theft didn’t get them in, no = it did.
- Don’t expose Port 3389 directly. A reverse-proxy gateway with strong auth (Cloudflare Zero Trust, Tailscale, Twingate, or a self-managed Remote Desktop Gateway behind a WAF) makes the actual RDP service unreachable from the open internet. Most ransomware crews are opportunists, if your gateway requires a separate authentication step they don’t bother.
- Treat session cookies as credentials. When an analyst’s session is compromised via cookie theft, the attacker doesn’t need a password OR an MFA token, they replay the issued session. Configure short session lifetimes (4–8 hours, not 30 days) for any admin-tier RDP role, and enforce token-binding where the IdP supports it.
- Monitor for impossible-travel and unusual-hour logins. Most successful RDP intrusions in our IR data show an authentication signal that would have been suspicious if anyone was looking, login from a country the employee has never visited, at 3am their time, from an autonomous-system range that’s appeared in threat feeds. Cheap to detect, almost never detected.
- Run a stealer-log exposure check on your domain monthly. The free Stealercheck covers this. If your domain shows fresh staff credential exposure, force a password reset and revoke any active sessions on the affected accounts before the credentials are weaponised.
- Patch the RDP service stack on a schedule, not on a crisis. The CVEs that lead to RDP compromise in 2026 are almost always 12+ months old. A 30-day SLA for RDP-touching servers eliminates a vector class.
- Audit who has RDP access quarterly, not annually. Half of the “insider / departed-employee” cases we see are accounts that should have been disabled 18 months ago.
- Log RDP authentication into your SIEM, not just to the local event log. Local Event ID 4624 / 4625 is useful right up until the attacker disables it. Ship to a SIEM where they can’t reach.
What detection looks like
The single highest-value alert most SOCs can stand up this week: a “successful RDP login from outside business hours and outside the user’s typical geo” rule. Combined with a “first time this user has authenticated from this IP range” enrichment, it’ll catch most of the brokered-credential pattern (the dominant one) before the attacker pivots. Most SIEM platforms have a templated rule for this, Microsoft Sentinel’s SecurityEvent analytics rules are a good starting point.
Frequently asked questions
Should we just turn RDP off entirely?
If you can run your admin operations through SSH + a VPN + Zero Trust without breaking your team’s workflow, yes. Most organisations can’t, which is why the realistic answer is to wrap it correctly, not to remove it. The question isn’t “is RDP exposed?”, it’s “what does an attacker need to defeat to use it?”
Is Windows Hello / passkeys actually phishing-resistant for RDP?
Yes when configured correctly, Windows Hello for Business with a TPM-backed hardware-bound credential cannot be phished via an AitM proxy. The catch is the configuration, many deployments fall back to passwords for legacy clients, which negates the protection. Audit your fallback paths.
How do we know if our credentials are already in a stealer log?
Run a domain check through Stealercheck. If the staff_total count is non-zero, force a password reset on the affected domain users and revoke all active sessions. For per-account confirmation you need verified domain ownership with a dark-web monitoring vendor like Alerts.bar.
What about RustDesk and AnyDesk? Same advice?
Same threat model, any remote-administration tool that’s reachable from outside the network needs the same wrap. The 2024–2025 wave of attacks against managed-service-provider RustDesk and AnyDesk deployments shows that “but it’s not RDP” is not the protection people think it is.
How quickly does a stolen credential get weaponised?
Median in our IR data: 11 days from infostealer infection to ransomware deployment. The fastest case we worked: 3 hours. The slowest: 19 months. The “wait it out” model doesn’t apply.
Related Ransomnews coverage
- Stealercheck, free domain-level exposure check against the stealer-log economy.
- Ransomtracker, live index of active ransomware operations and their published victims.
- Alerts.bar review, the dark-web monitoring platform we use in production for per-record exposure intelligence.
- Best antivirus 2026, endpoint protection that catches stealer infections before credentials leave the device.
- Best ransomware-resistant backup, the last line of defence when RDP defence fails.
Keywords: RDP attack landscape 2026, Remote Desktop ransomware entry vector, RDP brute force, BlueKeep CVE-2019-0708, stolen RDP credentials, initial access broker RDP, exposed RDP Shodan, RDP gateway hardening, phishing-resistant MFA RDP, stealer log RDP credentials, ransomware initial access 2026.
