Never hand over your RDP credentials: remote desktop, remote work, and the password you should never type twice

Remote desktop stopped being a specialist tool somewhere around March 2020. What had been the preserve of system administrators became the way entire finance departments reached their applications, and the way a contractor in another country fixed a server they had never physically seen. The tooling did not change much. The blast radius did.

This piece is about one habit in particular: giving your remote desktop credentials to somebody else, or typing them somewhere they will be left behind. It is the single most reliable way organisations lose control of their estate, and it is almost always done helpfully.

In this article

• The two ways credentials leave your control
• How RDP became the most common front door
• Comparing the ways people expose remote desktop
• Why the credential you type is the credential you lose
• “Just send me your login” — the social path
• Contractors, vendors, and standing access
• Where direct peer-to-peer connections belong
• A practical checklist
• If you have already handed them over
• How MangoSSH handles it

Overview

Credentials escape in two distinct ways, and conflating them leads to controls that only address half the problem.

You hand them to a person

Someone asks. A vendor needs to troubleshoot, a colleague is covering your shift, a caller claims to be from IT. The credential is transferred deliberately, by a person who believes they are being reasonable. No exploit is involved and no alarm fires.

You leave them on a machine

You type them into a remote desktop session, and depending on how that session was configured, they remain in memory on the far end. Nobody handed anything over. If that machine is later compromised, the attacker inherits whatever you signed in with — which, for an administrator, is usually a great deal.

The first is a policy problem. The second is a configuration problem. Both end with your credential in someone else's possession.

How RDP became the front door

The numbers are not subtle. Sophos' incident response team reported that RDP was abused in 90% of the attacks they handled in 2023. Unit 42 put RDP as the initial vector in roughly half of ransomware cases as far back as 2020, and an FBI agent quoted widely in the trade press put the figure at 70–90% of initial footholds.

The mechanism is unglamorous. Port 3389 gets opened during a rushed migration to remote working, or for one contractor, or “temporarily”. Attackers scan for it continuously — internet-wide scans have found millions of exposed endpoints — and then work through credential stuffing using passwords harvested from unrelated breaches. Access to the ones that answer is sold on, as a product, to whoever wants to deploy ransomware next.

Note what is absent from that description: a vulnerability. In most cases nothing is exploited. Someone simply logs in.

Comparing the exposure models

The credential you type is the credential you lose

This is the part that surprises people who have been administering Windows for years.

In a standard RDP session, your credentials are sent to and cached on the machine you connect to. Connect to twenty servers with a domain administrator account and you have deposited that account's material on twenty machines, each of which is now as sensitive as the account itself. Compromise any one, dump memory, and the attacker has your credential without ever attacking you.

Windows offers two mitigations, and the difference between them matters:

Restricted Admin mode

The credential is not sent to the target. Useful — but it introduces its own hazard, because it permits authentication by hash. Attackers have been observed enabling Restricted Admin on machines they already control, precisely so they can pass-the-hash over RDP, which is otherwise not possible. A single registry value flips it on. Treat an unexpected change to that setting as an indicator of compromise, not a hardening win.

Remote Credential Guard

Credentials stay on your machine; the target asks yours for service tickets as it needs them. Nothing in memory on the far end holds your password or its hash, so there is nothing there to dump. This is the stronger option where your environment supports it.

Neither is a default. Both require deliberate configuration, which is why so many estates are still depositing administrator credentials across every server in the building.

“Just send me your login”

The social path needs no technical sophistication at all. A call, an email, or a pop-up claims to be from tech support, a bank, or the helpdesk. There is urgency. The caller is friendly and competent-sounding. They ask you to install a legitimate remote access tool — and then they ask for the credential, or simply for control of the screen while you remain signed in.

Everything after that is ordinary use of ordinary software. Files are read, browsers are opened, additional tools are installed. Nothing in the security stack objects, because nothing anomalous is happening: an authorised user granted a remote session.

The rule that survives contact with reality is blunt. Nobody legitimate needs your password. Not your helpdesk, not your vendor, not your bank, not the person on the phone who knows your ticket number. A support engineer who genuinely requires access should be given their own account, scoped and revocable, and the session should be recorded.

Contractors, vendors, and standing access

The most durable version of this problem is not a scam call. It is the managed service provider who was given a shared administrator credential in 2021, for a project that ended in 2022, using an account whose password has not changed since.

Third-party access tends to accumulate the properties you would least want: it is shared, it is standing, it is rarely reviewed, and it is attributed to a company rather than a person. When something goes wrong, the log says an account connected. It cannot say who.

The fix is structural rather than technical. Named accounts per individual, not per organisation. Access that expires by default and has to be renewed. Rotation after the engagement ends, not eventually. And a recording of the session, so that “what did the vendor do on Tuesday” is a question with an answer.

Where direct peer-to-peer connections belong

Peer-to-peer remote desktop — where a machine listens and a viewer dials it directly, without a broker in the middle — is genuinely useful. It is also the configuration most often deployed in exactly the wrong place.

The security of a direct connection is entirely the security of the network path. There is no gateway performing authentication before the listener is reached, and no policy layer to consult. What protects the listener is that nobody unauthorised can route to it.

That makes direct P2P appropriate in a specific set of environments:

• Air-gapped or physically isolated networks, where reachability is a property of the building.
• Enterprise LANs and management VLANs, already segmented away from general user traffic.
• Private overlay networks — a WireGuard or similar mesh — where the listener binds to a tunnel address that does not exist on the public internet.
• Lab and test environments with nothing of value behind them.

It is not appropriate on a listener bound to a public address, on a laptop that moves between untrusted networks, or anywhere “direct” has quietly come to mean “port-forwarded through the office router”. If you cannot state precisely who can route to the listening port, you do not have a closed environment — you have an exposed one you have not finished measuring.

A practical checklist

In rough order of how much risk each removes:

1. Take RDP off the public internet. Nothing else on this list matters as much.
2. Put a gateway or broker in front of it, so the protocol is never directly reachable.
3. Turn on network level authentication, and require multi-factor for anything privileged.
4. Enable Remote Credential Guard where you can, so administrator credentials stop accumulating on servers.
5. Monitor for unexpected Restricted Admin registry changes as a compromise signal.
6. Give every human their own account. Retire shared administrator logins.
7. Make third-party access expire by default.
8. Record privileged sessions, and check that the recordings are findable.
9. Rotate anything that has ever been read aloud, pasted into a chat, or typed on a machine you do not control.
10. Bind direct peer-to-peer listeners to private or mesh addresses only.

If you have already handed them over

Speed matters more than diagnosis. Rotate the credential first and investigate afterwards — the reverse order gives an attacker the length of your investigation to establish persistence.

Then: end the remote session and remove whatever tool was installed; rotate anything the account could reach, not merely the account itself; check for accounts created during the window; and look for scheduled tasks or services added while the session was live. Access purchased or stolen is routinely resold, so the absence of immediate damage means very little.

How MangoSSH handles it

MangoSSH offers several routes to a Windows desktop, and the differences between them are precisely the ones this article is about.

RD Gateway, the enterprise route

Connections ride Microsoft's RD Gateway transport, so RDP is reached through an authenticated HTTPS endpoint rather than an exposed 3389.

Direct IP Access, for closed networks

The host listens and a viewer dials it directly — typically over a private WireGuard mesh address. Fast, no third party in the path, and safe exactly to the extent that the network is. It is built for the closed environments described above, not for the open internet.

A broker, so the credential is never handed over

For shared and privileged accounts, the session is brokered rather than the password shared. RDP makes this harder than SSH does: an SSH broker can forward an opaque byte stream, but an RDP credential is consumed during the NLA/CredSSP handshake and is bound to that TLS session, so it needs its own path. MangoSSH implements one instead of falling back to “just give the user the password”.

Credentials that stay put

Passwords live in Windows Credential Manager, macOS Keychain or Linux Secret Service, or in an encrypted vault — not in a config file, and not in a message to a colleague.

Sessions you can review

Privileged sessions are recorded to an encrypted, browsable store, so third-party access is answerable after the fact.

None of this removes the need for the discipline above. It only makes the safe path the convenient one, which is usually what determines whether a policy survives its first busy week.