Remote Desktop Protocol (RDP) is a protocol Microsoft developed to enable remote graphical communication. RDP implementations exist for other operating systems, but RDP is most popular on systems running Windows NT 4.0 and newer.

Older versions of RDP are unencrypted, while newer versions offer SSL and TLS encryption.

Standard RDP servers listen on port 3389 TCP. Administrators can configure the service to listen on any port, however. The following material investigates the process by which a simulated intruder gains access to a system via RDP. First he makes many connections to the RDP server, testing usernames and passwords. Following the correct guessing of a username and password, he connects and briefly interacts with the system offering access via RDP.

For full details on each field in the rdp.log file, please refer to RDP::Info.


Let’s start with the conn.log for the activity in question. I’ve broken it into two sets of activities. The first is the reconnaissance and the second is the interactive session.

I’ve summarized the first set of conn.log entries using the following syntax:

$ jq -c '[."id.orig_h", ."id.resp_h", ."id.resp_p", ."service", ."orig_bytes", ."resp_bytes"]' conn.log | sort | uniq -c
38 ["","",3389,"ssl",1392,1238]
 1 ["","",3389,"ssl",3365,4855]

We see 38 sessions which contain the same number of bytes sent and received by the client and server, and 1 session which contains a different number of bytes. That could indicate a successful connection. Port 3389 TCP is the destination, but remember that any TCP port could host a RDP server. Also note Zeek reports the service as SSL, because this RDP session is encrypted by TLS.

The second set of conn.log entries contains the following session:

  "ts": 1607353272.790635,
  "uid": "CFdEZNjN5MtPzGMS8",
  "id.orig_h": "",
  "id.orig_p": 59758,
  "id.resp_h": "",
  "id.resp_p": 3389,
  "proto": "tcp",
  "service": "ssl",
  "duration": 109.49137687683105,
  "orig_bytes": 66747,
  "resp_bytes": 1823511,
  "conn_state": "RSTR",
  "missed_bytes": 0,
  "history": "ShADdaFr",
  "orig_pkts": 2913,
  "orig_ip_bytes": 183287,
  "resp_pkts": 2250,
  "resp_ip_bytes": 1913523

This activity is similar to the previous, except that the client and server have sent many more bytes of data.


The following syntax summarizes the relevant content in the first set of Zeek rdp.log entries, caused by the simulated intruder’s RDP reconnaissance:

$ jq -c '[."id.orig_h", ."id.resp_h", ."id.resp_p", ."cookie", ."result", ."security_protocol", ."cert_count"]' rdp.log | sort | uniq -c
39 ["","",3389,"test","encrypted","HYBRID",0]

There is nothing in these logs to indicate whether the session was successful or not. However, Zeek was able to determine that RDP was in use, based on its recognition of the protocol.

Here is the entire rdp.log entry for the interactive RDP session:

  "ts": 1607353272.791158,
  "uid": "CFdEZNjN5MtPzGMS8",
  "id.orig_h": "",
  "id.orig_p": 59758,
  "id.resp_h": "",
  "id.resp_p": 3389,
  "cookie": "test",
  "result": "encrypted",
  "security_protocol": "HYBRID",
  "cert_count": 0

As before, there is nothing stating that this is an interactive session.

ssl.log and x509.log

The Zeek logs associated with TLS-encrypted sessions might tell us a bit about the RDP server. Here is a ssl.log entry for the interactive session:

  "ts": 1607353272.79572,
  "uid": "CFdEZNjN5MtPzGMS8",
  "id.orig_h": "",
  "id.orig_p": 59758,
  "id.resp_h": "",
  "id.resp_p": 3389,
  "version": "TLSv12",
  "cipher": "TLS_RSA_WITH_AES_256_GCM_SHA384",
  "server_name": "",
  "resumed": false,
  "established": true,
  "cert_chain_fuids": [
  "client_cert_chain_fuids": [],
  "subject": "CN=WinDev2010Eval",
  "issuer": "CN=WinDev2010Eval"

From this information it looks like the target is a Windows development server.

Here is the corresponding x509.log entry. We match it to the preceding ssl.log entry using the id field.

  "ts": 1607353272.79572,
  "id": "FWesoX2H43hXhuqoGb",
  "certificate.version": 3,
  "certificate.serial": "5578FF9983F26AA6442533AB6AD54C72",
  "certificate.subject": "CN=WinDev2010Eval",
  "certificate.issuer": "CN=WinDev2010Eval",
  "certificate.not_valid_before": 1602434171,
  "certificate.not_valid_after": 1618245371,
  "certificate.key_alg": "rsaEncryption",
  "certificate.sig_alg": "sha256WithRSAEncryption",
  "certificate.key_type": "rsa",
  "certificate.key_length": 2048,
  "certificate.exponent": "65537"

While this might have some significance in other investigations, here it is not as important.

Running the Test

For those who might want to simulate this activity themselves, I wanted to share how I conducted this experiment.

$ hydra -t 1 -V -f -l test -P wordlist.txt rdp://
Hydra v9.1 (c) 2020 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-12-07 09:46:30
[WARNING] the rdp module is experimental. Please test, report - and if possible, fix.
[DATA] max 1 task per 1 server, overall 1 task, 4999 login tries (l:1/p:4999), ~4999 tries per task
[DATA] attacking rdp://
[ATTEMPT] target - login "test" - pass "123456" - 1 of 4999 [child 0] (0/0)
[ATTEMPT] target - login "test" - pass "12345" - 2 of 4999 [child 0] (0/0)
[ATTEMPT] target - login "test" - pass "123456789" - 3 of 4999 [child 0] (0/0)
[ATTEMPT] target - login "test" - pass "password" - 4 of 4999 [child 0] (0/0)
[ATTEMPT] target - login "test" - pass "liverpool" - 38 of 4999 [child 0] (0/0)
[ATTEMPT] target - login "test" - pass "football" - 39 of 4999 [child 0] (0/0)
[3389][rdp] host:   login: test   password: football
[STATUS] attack finished for (valid pair found)
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2020-12-07 09:46:53

I used the reconnaissance tool THC-Hydra by van Hauser/THC & David Maciejak. I provided a word list that had a password that I had enabled on a test account on the Windows RDP server at I ran Hydra from a Kali Linux virtual machine against a Windows 10 development virtual machine and captured the traffic on Kali Linux. I then processed it with Zeek to produce the logs in this section.


When processing unencrypted RDP sessions, Zeek can provide a bit more information than that provided here. However, in my experience Zeek is most helpful for identifying systems which should or should not be offering RDP services. Zeek will also generate records for interactive sessions, helping analysts identify when authorized or unauthorized users access systems via RDP.

For more information on analyzing RDP in context of vulnerabilities that appeared in 2020, please see the following blog posts: