mstsc RDP client with unsafe written over itIn this article, we will demonstrate why connecting using the Remote Desktop Protocol (RDP) must be avoided on untrusted networks like in hotels, conferences, or public Wi-Fi. Protecting the connection with a VPN or a Remote Desktop Gateway is the only safe alternative.

We have been working on and studying RDP for a long time. We develop and maintain a comprehensive RDP attack and interception toolkit called PyRDP. By pushing our exploration of the protocol with PyRDP we have come to realize that it is dangerous and irresponsible to use RDP on untrusted networks and we realize that this risk is badly documented on the Web.


RDP Trust Primer

RDP’s remote host authentication model can be compared with HTTPS or SSH. With HTTPS we rely on the browsers to distribute the trust anchors required to validate the individual target sites we visit. The trust anchors, certificate authorities in this case, signed the target sites and so the cryptography is sound. It’s a public key infrastructure or PKI for short.

SSH operates under a “Trust on First Use” model or TOFU where you are presented with the fingerprint of the host the first time you connect to it. You accept that fingerprint and it is saved in your client. If, when connecting later, the server’s host key fingerprint has changed you would be presented with a scary message saying you are at risk.

RDP Certificate WarningRDP from the end-user’s perspective exposes an HTTPS-like behavior with certificate warnings. Microsoft would like people to use and rely on PKI but that is not done by default and is too complex for most organizations. Instead, it presents certificate warnings by default because most of the time the server’s certificate is untrusted. Then there is the option “Don’t ask me again for connections to this computer” which, one would think would act like an optional and unclear “Trust when I clicked don’t ask me again” analogous to SSH but that’s not quite that as you will see later.


The Problem

We knew it was possible to capture the Net-NTLMv2 hashes of RDP users for a while. In fact, Responder was the first tool to support it. We implemented the same attack in PyRDP last year. You can read about the technical details in a previous blog post about the attack.

PyRDP Stealing the Net-NTLMv2 Hash of a Victim

Since then, we discovered that the hashed credentials can be stolen before any certificate warnings or errors are displayed. This is even the case if the “Don’t ask me again […]” was clicked on the certificate error.

We reported the problem to Microsoft (case id: 71482), and this is what they told us:



Engineering has completed their assessment of your case and have ranked it as


severity=none, impact=not a vulnerability, resolution=by design


Their explanation states the NTLMv2 hash is sent during CredSSP authentication which must occur before any certificate warnings can be displayed


As a result, I will be closing this case.

Microsoft basically acknowledges that this is a protocol design mistake and that its engineering is not willing to fix the problem. Note that no alternate secure authentication mechanism was offered. The good old “Won’t fix, as designed” treatment.



Here is a video demo demonstrating the attack:


What Does This Imply?

A hash of your password can be captured by any adversary on the network path to the server. These types of hashes are called NetNTLMv2 hashes and are potentially recoverable by an attacker depending on the password complexity, its presence in public password databases like RockYou2021 (that holds 8 billion passwords) and the resources of the attacker. Given the risks and the fact that this happens in an undetectable fashion (prior to certificate errors) we advise that RDP must not be used on any untrusted networks like public Wi-Fi or over the Internet without additional transport security like a VPN. In some contexts, multi-factor authentication can mitigate that risk if the original password is strong enough.


Closing Thoughts

We are a bit disappointed by Microsoft’s response to the vulnerability report. We realize that preventing the attack is complex. This is a design mistake in a publicly documented protocol with 3rd party implementations. The worst kind of mistake to fix. We are compassionate with their position, but we feel they are sweeping the problems under the rug. Their documentation does not mention any client-side level risks and we are unaware of any public roadmap that would enable later protocol versions to get rid of these problems. This blog post aims to document this RDP flaw in simple language and with a demonstration of the impact.

In an upcoming blog post, we will look at RDP’s certificate verification and how easy it is to trick.

GoSecure Titan® Managed Extended Detection & Response (MXDR)​

GoSecure Titan® Managed Extended Detection & Response (MXDR)​ Foundation

GoSecure Titan® Vulnerability Management as a Service (VMaaS)

GoSecure Titan® Managed Security Information & Event Monitoring (SIEM)

GoSecure Titan® Managed Perimeter Defense​ (MPD)

GoSecure Titan® Inbox Detection and Response (IDR)

GoSecure Titan® Platform

GoSecure Professional Security Services

Incident Response Services

Security Maturity Assessment

Privacy Services

PCI DSS Services

Penetration Testing Services​

Security Operations


GoSecure MXDR for Microsoft

Comprehensive visibility and response within your Microsoft security environment


Cyber Risks

Risk-Based Security Measures

Sensitive Data Security

Safeguard sensitive information

Private Equity Firms

Make informed decisions

Cybersecurity Compliance

Fulfill regulatory obligations

Cyber Insurance

A valuable risk management strategy


Combat ransomware with innovative security

Zero-Day Attacks

Halt zero-day exploits with advanced protection

Consolidate, Evolve & Thrive

Get ahead and win the race with the GoSecure Titan® Platform


GoSecure Titan® Endpoint Detection and Response (EDR)

GoSecure Titan® Next Generation Antivirus (NGAV)

GoSecure Titan® Network Detection and Response (NDR)

GoSecure Titan® Inbox Detection and Reponse (IDR)

GoSecure Titan® Intelligence


GoSecure is a recognized cybersecurity leader and innovator, pioneering the integration of endpoint, network, and email threat detection into a single Managed Extended Detection and Response (MXDR) service. For over 20 years, GoSecure has been helping customers better understand their security gaps and improve their organizational risk and security maturity through MXDR and Professional Services solutions delivered by one of the most trusted and skilled teams in the industry.




24/7 Emergency – (888)-287-5858