Open RDP on the Public Internet: Found During Onboarding Discovery

Incident

During the discovery phase of onboarding a new East Tennessee business onto managed IT, we ran our standard external edge pass: public IPs, open ports, certificates, mail auth, and anything listening that shouldn’t be. One of the public addresses answered on TCP 3389 — Windows Remote Desktop — from the open internet.

No ticket. No “we can’t remote in.” No ransomware note. Just a door that had been left open long enough that we found it before a stranger did.

That is the point of discovery. You do not inherit a network and assume the last person locked it.

Timeline

The open port was the whole incident. No ticket, no ransomware note, no “we can’t remote in” call. Discovery found a door that had been left open long enough that we got there first. Everything after 09:25 is containment and a permanent path so the next person who needs remote access does not recreate the same hole.

Why open RDP is a problem

Remote Desktop is a full interactive session into a Windows machine. Exposed to the public internet it becomes:

• A constant target for credential stuffing and brute force (RDP is on every scanner list)
• A path for ransomware operators who buy access or spray weak passwords
• A bypass of every internal control you think you have, because authentication happens at the edge with whatever password still works

“We only use it sometimes” does not shrink the attack surface. Bots do not wait for business hours. If 3389 is reachable from a coffee shop in another country, it is reachable from a botnet.

For firms in regulated spaces — manufacturing with OT adjacency, title and law handling money, medical and finance with data obligations — internet-facing RDP is also an audit and insurance problem. Cyber carriers and security questionnaires ask about remote access. “RDP open to the world” is the wrong answer. Closing it is part of managed network monitoring and edge hygiene, not a one-off firewall favor.

Root cause

Almost never malice. Almost always habit:

• A vendor needed in “just for this project” years ago
• A prior IT shop preferred RDP over a VPN and never cleaned up the firewall rule
• A router port-forward that survived a firewall upgrade
• An owner who works from home and wanted “the easy way”

In this case it was a leftover remote-access path from before we managed the environment. The business had been living with it. Nobody was watching the logons the way a managed baseline does.

Response

Same-day containment, then a proper path:

1. Confirmed scope — which host, which public IP, which firewall object, whether anything else forwarded 3389.
2. Closed the public hole — removed the allow rule so 3389 was no longer reachable from the internet.
3. Preserved legitimate need — admins still need remote access; we put them on a VPN or jump host, then RDP only on the private side.
4. Hardened what remains — network-level restriction, account hygiene, and monitoring so failed RDP attempts on the internal path still get seen.
5. Documented the finding — discovery notes for the client: what was open, what we closed, what the permanent pattern is.

No confirmed compromise. We treated the exposure as the incident.

Outcome

Public RDP closed the same day. Admin access moved behind VPN/jump. No evidence of prior compromise in this case — the win is that discovery caught the gun on the table before someone else picked it up.

If you manage your own edge (or you just hired an MSP and they have not shown you an external scan), ask:

• Is any host listening on 3389, 22, or other admin ports from 0.0.0.0/0?
• Who approved that rule, and is the project that needed it still active?
• If someone needs remote desktop, is there a VPN (or Zero Trust / jump box) in front of it?
• Are failed logon attempts on RDP monitored, or does the noise go nowhere?

A free external port scan of your own public IPs is not advanced security. It is hygiene. We run it on every onboarding for a reason.

Key takeaways