Decoding RDP RRS feed

  • Question

  • Greetings,

    I am trying to parse for certain fields of the Remote Desktop Protocol packets exchanged during a remote connection session, specifically the login credentials, and I am having a lot of trouble with the decoding procedure. For reference, in the v20151016 edition of the [MS-RDPBCGR] document (, an encrypted packet dump is displayed in Section 4.1.10 Client Info PDU (p. 331). On the next page, the decrypted version of the same dump is displayed, and the contents are decoded and shown in ASCII. I am basically trying to collect the same output in my own lab. In order to obtain human-readable RDP packet info, the session must be decompressed, decrypted and decoded. The following is what I have done thus far to try to do just that.

    As I control both the client and the server in my lab, I should have access to everything I need to get the information I want. Decompression is relatively easy to handle. On the server, I disable it by editing group policy:

    Local Computer Policy > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Configure compression for RemoteFX data > Enabled > Do not use an RDP compression algorithm

    On the client, I edited the .rdp configuration file by changing




    That should take care of the compression obstacle. Next, onto the decryption problem. Again, as I control the server, I have access to the private key in the certificate used for SSL/TLS encryption. This certificate can be found using Microsoft Management Console (mmc.exe):

    Console Root\Certificates (Local Computer)\Remote Desktop\Certificates

    Although the private key from this certificate is marked as non-exportable, I was able to bypass that obstacle. Long story short, I have the .pfx file if I need it, from which I can use openssl on my Linux box to extract the key.

    I think I was able to successfully decrypt an RDP session using Network Monitor by following the instructions from Bryan S. Burgin's awesome blog ( I think I was able to obtain similar results with Message Analyzer with instructions by the same author ( However, the decrypted packet dumps are still not human-readable. Wireshark can decrypt SSL sessions, and apparently they had an RDP parser or "dissector" at one time, but this is no longer true ( The TPKT dissector does not seem to fit the bill, either.

    Lastly, I had decided to go old school and crack out Cain and Abel to run a man-in-the-middle attack between my RDP client and server ( Cain was able to decrypt the session, and although it can figure out which packets represent keystrokes and decrypt those packets, they are still displayed in encoded form.

    The issue apparently is that, although RDP sessions can be decrypted, I don't seem to be able to find a way to decode them in order to render them human-readable. I've been researching on how to do this for over a week, and I'm wondering whether the authors of the [MS-RDPBCGR] document had access to specialized tools not available to the public, as RDP is after all a Microsoft proprietary protocol.

    In the same document, a Password field is listed in Section Info Packet (TS_INFO_PACKET) on p. 70. However, I believe this field only records saved credentials. If you are logging into a machine via RDP for the first time or have to re-enter your credentials, the password is sent via separate packets as keystrokes. Of course, until I can decode the packets, I cannot confirm this theory one way or the other.

    Can anyone please assist?

    Thank you in advance!







    Friday, January 22, 2016 5:39 PM

All replies

  • Hi joel.mcintyre25,

    Thank you for your question about remote desktop login credentials decoding. One of the Open Specifications team members will respond shortly to begin working with you.

    Best regards,
    Tom Jebo
    Sr Escalation Engineer
    Microsoft Open Specifications

    Friday, January 22, 2016 5:57 PM
  • Hi Joel,

    I can help you with this.  Thank you for your kind words regarding my blog.  It wasn't entirely clear if you ultimately got decrypted packets and now your focus is just the Password field or if basic decrypting is still an issue.

    The steps are really only necessary when trying to obtain human-readable traces using MSTSC as a client.  For your own client, you can turn off client-to-server encryption yourself and disable server-to-client encryption by setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\MinEncryptionLevel to (DWORD) 1.

    Since my blog and presentation, some other steps must be taken: TLS has to be downgraded to TLS 1.0 or 1.1, as NmDecrypt doesn't understand TLS 1.2.  And, cypher suites that use elliptical curves cannot be used, so the client must be tweaked (via GPEdit) to remove them in the TLS client handshake.

    Can you e-mail me at "dochelp (at) Microsoft (dot) com" and we can work through this together?  Once we get a result, I'll update this forum thread for everyone else.

    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Friday, January 22, 2016 6:20 PM
  • Update to forum.

    My RDP decryption techniques outlined in my blog are not working with current builds.  I am reviewing why that is and will determine if the issue can be mitigated or fixed.  I plan to update my blog post when this is resolved.

    In the meantime, I was able to unblock Joel's original issue regarding credentials by providing an archived decrypted trace.

    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, January 28, 2016 9:55 PM
  • Hi Bryan,

    Thanks for the wonderful blog and it really helps.

    I followed the steps given and I am able to see the first level CSSP decrypted packets with Windows Message Analyzer.  CSSP has double encryption for credentials - first one is TLS and second one is SPNEGO token. 

    But the problem with Windows Message Analyzer is it is not showing the password decrypted because authinfo in TSRequest is doubly decrypted. First one is with TLS and second one with SPNEGO token.

    How can we use Windows Message Analyzer to decode authinfo in TSRequest structure which is doubly encrypted.



    Thursday, March 26, 2020 2:32 PM
  • Forum Update:


    This question is being dealt with in an other thread in this same forum:

    Regards, Obaid Farooqi

    Friday, March 27, 2020 11:44 PM