Decrypt RDP Traffic with Wireshark and Frida [Step-by-Step]

What is RDP?

Remote Desktop Protocol (RDP) is a protocol developed by Microsoft and used to manage a computer remotely. A client can connect to another computer through a network connection and manage it as if he/she is sitting at in front of his/her computer. The protocol uses TCP port 3389 and UDP port 3389 in default.

 

RDP Security Layer

RDP Security Layer falls in two categories:

 

1. Standard RDP Security

Communication between the server and the client is protected by native RDP encryption. It uses RSA Security's RC4 cipher to secure all data being transferred to and from the Windows system. This cipher encrypts data of varying size with a 56-bit or a 128-bit key. I will start an RDP connection and show you a few packets how it selects an RDP Security Layer. Following screenshot shows an "RDP Negotiation Request" packet from the client to the server.

 

The client desires to use "Enhanced RDP Security" with specifying one of the methods below. It asks the server to pick one of them.

• "TLS security supported"
• "CredSSP supported"
• "Early user Authorization Request PDU supported"

Following screenshot shows "RDP Negotiation Failure" packet coming from the server.

Since the server does not support TLS which is used by "Enhanced RDP Security", it returns a failure code and specifies that TLS is not allowed. The client changes its decision and negotiates for "Standard RDP Security" with the packet below.

 

As you can see, all the flags in the "requestProtocols" are set to 0 (zero), which tells the server "lets use native RDP protocol". The server accepts the offer and responses accordingly. Following packet belongs to the server.

 

2. Enhanced RDP Security

RDP uses an external security protocol for "Enhanced RDP Security". All the security protocols involve TLS. The list of them are below:

TLS: In this method, RDP is encapsulated by TLS. When we decrypt the TLS external security protocol, we can see the client credentials (username and password) in clear text. Following figure shows that the RDP client is offering TLS security.

 

Credential Security Support Provider protocol (CredSSP): CredSSP is an authentication provider which processes authentication requests for other applications. CredSSP provides an encrypted Transport Layer Security Protocol channel. The client is authenticated over the encrypted channel by using the Simple and Protected Negotiate (SPNEGO) protocol with either Microsoft Kerberos or Microsoft NTLM. Although it uses TLS, when it is decrypted, you can not see the user credentials in clear text. Following screenshot shows an NTLM authentication provided by CredSSP inside a decrypted TLS tunnel.

 

When CredSSP is used as the external security protocol , it enables the use of Network Level Authentication (NLA).

RDSTLS: It is a variation of Enhanced RDP Security that is primarily used in the context of server redirection scenarios. Server authentication, encryption, decryption, and data integrity checks are implemented by leveraging the TLS security protocol, while user authentication is accomplished by exchanging RDSTLS PDUs directly following the TLS handshake. In short, it uses NTLM inside TLS.

 

Installing Frida and capturing TLS Premaster keys

Frida is a tool that can be used to obtain TLS session keys used by RDP.

Step-1: Install Python. I will download and install it on a Windows. You can download it here (https://www.python.org/downloads/release/python-380/).

 

Step-2: Go to python home and use ".\Scripts\pip.exe install frida-tools frida" to install it. My home folder is:

"C:\Users\administrator.MYDOMAIN\AppData\Local\Programs\Python\Python38>"

Following screenshot shows the installation.

 

Step-3: Download keylog.js from here:

https://github.com/ngo/win-frida-scripts/blob/master/lsasslkeylog-easy/keylog.js and save it to a directory. We will use that path in the next step.

 

Step-4: Launch Windows PowerShell as administrator. Then go to python home and run the command below. Do not forget to modify it for yourself.

PS C:\Users\administrator.MYDOMAIN\AppData\Local\Programs\Python\Python38\Scripts> frida.exe --no-pause lsass.exe -l C:\keylog.js

You should see an output like below.

When you connect to an RDP server, Frida will collect the keys in the C:\keylog.log file.

 

Wireshark RDP Decryption

If you feed Wireshark with session keys or a private key of PKI, it can decrypt TLS/SSL traffic.

Step-1: Launch Wireshark and navigate to Edit → Preferences.

 

Step-2: A window appears and expand the "protocols" tree.

 

Step-3: Find TLS and click on it. From left pane, click on "Browse" button to select "keylog.log". Remember that the file path is "C:\keylog.log" in default. Click "OK" to finish. Then restart Wireshark.

 

Step-4: Capture the packets while starting an RDP session.

Step-5: Wireshark automatically decrypt the TLS traffic. Next, find "ClientInfo" packet and expand the tree. You should see the RDP username and password fields in clear text. My output is below.

 

Changing RDP Security Layer Protocols

Windows lets you set specific security layer for RDP through Group Policy.

Step-1: Open "Local Group Policy Editor" and expand "Administrative Templates". Then click on "Windows Components".

 

Step-2: Find "Remote Desktop Services" and click on "Security".

 

Step-3: At the right pane, you will see "Require use of specific security layer for remote (RDP) connections". Double click on it and the configuration window will open. Select "Enable" option and then, select the "Security Layer" you want from the dropdown list.

 

According to Microsoft:

This policy setting specifies whether to require the use of a specific security layer to secure communications between clients and RD Session Host servers during Remote Desktop Protocol (RDP) connections.

If you enable this policy setting, all communications between clients and RD Session Host servers during remote connections must use the security method specified in this setting. The following security methods are available:

• Negotiate: The Negotiate method enforces the most secure method that is supported by the client. If Transport Layer Security (TLS) version 1.0 is supported, it is used to authenticate the RD Session Host server. If TLS is not supported, native Remote Desktop Protocol (RDP) encryption is used to secure communications, but the RD Session Host server is not authenticated. Native RDP encryption (as opposed to SSL encryption) is not recommended.
• RDP: The RDP method uses native RDP encryption to secure communications between the client and RD Session Host server. If you select this setting, the RD Session Host server is not authenticated. Native RDP encryption (as opposed to SSL encryption) is not recommended.
• SSL (TLS 1.0): The SSL method requires the use of TLS 1.0 to authenticate the RD Session Host server. If TLS is not supported, the connection fails. This is the recommended setting for this policy.

If you disable or do not configure this policy setting, the security method to be used for remote connections to RD Session Host servers is not specified at the Group Policy level.

 

Discovering RDP Security Layer with Nmap Scanning

Nmap provides a Nmap Scripting Engine (NSE) script called "rdp-enum-encryption" that determines which Security Layer and Encryption Level is supported by the RDP service. I ran the script and the result is below.

celal@kali:~$ nmap -p 3389 192.168.1.21 -script rdp-enum-encryption
Starting Nmap 7.80 ( https://nmap.org ) at 2022-03-04 17:34 EST
Nmap scan report for 192.168.1.21
Host is up (0.00051s latency).

PORT     STATE SERVICE
3389/tcp open  ms-wbt-server
| rdp-enum-encryption:
|   Security layer
|     CredSSP (NLA): SUCCESS
|     CredSSP with Early User Auth: SUCCESS
|     Native RDP: SUCCESS
|     RDSTLS: SUCCESS
|     SSL: SUCCESS
|   RDP Encryption level: Client Compatible
|     40-bit RC4: SUCCESS
|     56-bit RC4: SUCCESS
|     128-bit RC4: SUCCESS
|     FIPS 140-1: SUCCESS
|_  RDP Protocol Version:  RDP 5.x, 6.x, 7.x, or 8.x server

 

Final thoughts

RDP can be vulnerable especially when Native RDP is used, which is protected by Standard RDP Security layer. CredSSP with NLA is the best option to go with. It is more secure and robust. Since all Enhanced RDP Security methods use TLS, it is possible to decrypt RDP protocol.

 

References

https://www.cyberark.com/resources/threat-research-blog/explain-like-i-m-5-remote-desktop-protocol-rdp
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/592a0337-dc91-4de3-a901-e1829665291d
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770833(v=ws.11)?redirectedfrom=MSDN
https://docs.oracle.com/cd/E35310_01/E35309/html/Windows-Network-Security.html
https://www.netwoven.com/2018/05/15/solved-credssp-encryption-oracle-remediation/
https://docs.microsoft.com/en-us/windows/win32/secauthn/credential-security-support-provider
https://b.poc.fun/decrypting-schannel-tls-part-1/