Your Windows server has a Remote Desktop port open because someone needed it once. Ransomware crews do not need to be clever about that. They need one reachable service and one working password, and this article walks through how those two things turn into an encrypted file server.
Short version of the attack chain
Human-operated ransomware is not a virus that wanders in. Microsoft describes it as hands-on-keyboard: attackers who get in, steal credentials, move through the network and only then deploy the payload. Its hallmarks, Microsoft says, are “credential theft and lateral movement with an elevation of the privileges in stolen accounts.”
RDP shows up at two points in that chain: as the way in, and as the way around once inside.
Step 1: Find an RDP service that answers
Remote Desktop listens on TCP port 3389 by default. If that port answers from the internet, anyone can try it. CISA’s #StopRansomware guide is blunt: “Threat actors often gain initial access to a network through exposed and poorly secured remote services, and later traverse the network using the native Windows RDP client.” Its first instruction on internet-facing services: “Do not expose services, such as remote desktop protocol, on the web.”
Microsoft lists “direct accessibility of systems on the public internet” as a security consideration for Remote Desktop and notes that attackers “continue to target the RDP” service. How scanners find these ports is covered in how attackers find open ports.
Step 2: Get a login that works
An open port is only a door. The attacker still needs a key, and CISA’s guide points at several ways to get one: compromised credentials, and brute force and password spraying, for which it advises you to “enforce account lockout policies after a certain number of failed login attempts” and to “log and monitor login attempts.”
Its Akira advisory describes the same pattern at the account level: “Akira threat actors obtain and abuse credentials of existing accounts to gain initial access.” A password stolen from one place is tried in another. A password that is merely weak is guessed. MFA is what makes both of those fail, and it is why CISA lists phishing-resistant MFA first in the Akira mitigations.
How common is RDP as a way in?
Common enough to name, not so common that everything else is noise. The numbers below are from one advisory about one group, so read them as a data point, not a league table.
| Source | What it says about RDP |
|---|---|
| CISA, BlackSuit (AA23-061A) | RDP compromise is “the second most common vector (around 13.3% of incidents)”; phishing is most common, per third-party reporting |
| CISA, Akira (AA24-109A) | “Akira threat actors leverage RDP connections as an initial access vector to victim systems” |
| CISA, #StopRansomware Guide | Lists “Compromised Credentials”, “Phishing” and “Internet-Facing Vulnerabilities and Misconfigurations” among six initial access vectors, without ranking them |
The honest takeaway: closing RDP does not make you ransomware-proof. Phishing still works. It does remove one of the routes, and it is one of the cheapest routes to remove.
Step 3: Move sideways, take more credentials
Getting onto one server is rarely the goal. CISA’s Akira advisory says the actors use credential scraping tools such as Mimikatz and LaZagne, and that they “also employ RDP” together with SSH to “expand their presence within the compromised network.” In the BlackSuit case, actors “used valid accounts to move laterally through the domain controller using RDP.”
Microsoft makes the same point about admin access: “Allowing administrative access of server and cloud systems directly through RDP elevates the risk.” If an admin account is the one that logs in over exposed RDP, the attacker has just skipped several steps. We cover containing this stage in what is lateral movement.
Step 4: Steal, then encrypt
Speed is the unpleasant part. CISA reports that “in some incidents, Akira threat actors exfiltrated data in just over two hours from initial access.” After that, “Akira threat actors use a double-extortion model”: they steal data, then encrypt systems and threaten to leak what they took. Restoring from backup fixes the encryption. It does not un-leak the data.
Where the chain can be cut
- Port 3389 answers anyone
- Login is the only barrier
- Sideways moves over RDP
- Data out in two hours, in some cases
- No inbound listener
- MFA on the one way in
- Account lockout and logging
- Admin access limited
Each step above has a control that matches it:
- Do not expose RDP. Audit for systems using it and, in CISA’s words, “close unused RDP ports.” The fuller argument is in is it safe to expose RDP to the internet.
- Put MFA on every remote path. CISA: “Implement MFA on all VPN connections.” The Akira advisory records actors getting in “through a virtual private network (VPN) service without multifactor authentication (MFA) configured,” so a VPN without MFA is not a fix.
- Use a gateway rather than a bare port. Microsoft says a Remote Desktop Services gateway “prevents the system hosting the remote desktop protocol services from being directly exposed to the public internet.” The gateway then becomes the exposed service, so patch and monitor it.
- Lock out and log. Account lockout after failed attempts, and logging of login attempts, both appear in CISA’s guide.
- Limit admin accounts. The BlackSuit advisory recommends least privilege and time-based access for admin-level accounts. Microsoft suggests just-in-time access with an approval workflow for administrative access.
Where SSHepherd fits
If your aim is to remove step one altogether, SSHepherd® closes the listening port on the Windows server. The server and your administrators connect outward to a broker, which joins them only for authorised identities, so a scan finds no 3389 to try. Sessions can be monitored, recorded and ended on demand. It does not stop phishing, and it does not replace MFA or patching. It removes the exposed listener. See the Windows RDP use case and the SSHepherd page.
The bottom line
Ransomware crews get in through RDP by finding an exposed port and logging in with credentials that were guessed, reused or stolen, then use RDP again to move sideways. Close the port, put MFA on whatever replaces it, and limit what an admin login can reach.