Remote access without opening ports: why exposed RDP keeps ending badly
Never forward RDP (3389) to the internet. Scanners find a newly exposed RDP service within minutes and start credential stuffing shortly after; changing the port only delays discovery by hours.
The safe patterns need nothing listening inbound: either a VPN, or an agent on the machine that makes an outbound, encrypted connection to a relay service, with sessions established through that connection. The client firewall stays closed in both cases.
What actually happens to an open 3389
Put an RDP service on a public address and it is in the scan data the same day. What follows is not clever: continuous password spraying against common usernames, at a rate designed to stay under lockout thresholds, forever. One reused or weak credential later and the attacker has an interactive desktop inside the network. Most of the ransomware write-ups that begin with initial access via RDP describe exactly this, and no patch fixes it because it is not a vulnerability; it is a login prompt facing the internet doing its job.
Moving RDP to another port defeats nobody: scanners fingerprint the protocol on any port. NLA and lockout policies raise the cost but the prompt is still public, and the occasional pre-auth vulnerability (as BlueKeep was) turns every exposed instance into an emergency at once.
The three patterns, honestly compared
| Pattern | Inbound exposure | The catch |
|---|---|---|
| Port-forwarded RDP | A public login prompt | See above. Do not. |
| VPN, then RDP inside | The VPN endpoint | Sound, but you now maintain the VPN, its MFA and its patching per site, and a flat network gives every VPN user broad reach. |
| Outbound agent + relay | None | You are trusting the vendor's control plane, so judge it: end-to-end encryption, MFA, audit logging. |
How the agent pattern works
An agent on the machine keeps one outbound, TLS-encrypted connection open to a control plane, the same direction as ordinary web traffic, so no firewall change is needed. When a technician starts a session, the signalling crosses that connection and the actual desktop stream is negotiated peer-to-peer where the network allows, falling back to a relay that carries only ciphertext. The machine never listens for anything.
Whatever vendor you use for this, hold it to the checklist: sessions encrypted end to end so the relay cannot see the screen, MFA on the technician side, an audit trail of who connected where, and something on the machine's screen telling the user a session is active.
This is how Moorfox is built.
Moorfox agents connect outbound only. Remote desktop and terminal sessions are encrypted end to end, media goes peer-to-peer where the network allows, and the machine shows who is connected. Nothing to open inbound, ever.
Frequently asked questions
Is changing the RDP port from 3389 enough to be safe?
No. Internet scanners fingerprint the RDP protocol itself on every port, so a non-standard port only delays discovery by hours. The exposure is the public login prompt, not the port number.
Is a VPN safer than an RMM agent?
Both remove the public login prompt, which is the main win. A VPN keeps everything self-hosted but adds per-site maintenance and often grants broad network reach. An agent needs no inbound exposure at all but places trust in the vendor’s control plane, so judge its encryption, MFA and audit logging.
How can an agent reach a machine with no ports open?
The agent makes the connection outbound, like a browser does, and keeps it open. Sessions are set up through that existing connection, and traffic flows either peer-to-peer or through a relay. Since nothing on the machine listens for incoming connections, there is nothing inbound to firewall.