Moorfox
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 require no inbound listeners. Use a VPN or an agent on the machine that makes an outbound, encrypted connection to a relay service. The client firewall stays closed in both cases.
What actually happens to an open port 3389?
Put an RDP service on a public address and it is in the scan data the same day. Continuous password spraying against common usernames follows, 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.
VPN, jump host or agent: which remote access pattern holds up?
| 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 carefully. Check for end-to-end encryption, MFA, and audit logging. |
How does agent-based remote access work without open ports?
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. The actual desktop stream negotiates peer-to-peer where the network allows. If the network blocks it, the stream falls back to a relay that carries only ciphertext. The machine never listens for anything.
Whatever vendor you use for this, hold it to this 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.