So the other day I stumbled upon this great article from Portcullis Labs. The article explains how you can man-in-the-middle an RDP SSL connection. This can be helpful in obtaining the user’s password, like Portcullis explains in their article. As far as I could tell they didn’t release their tool, so I decided to see if I could whip up a quick POC script with a twist of saving the entire decrypted stream to a pcap file. This would put you in the position to maybe retrieve more sensitive data then just the password. Turns out the only modification from regular SSL intercepting code is more or less the following:
#read client rdp data
serversock.sendall(clientsock.recv(19))
#read server rdp data and check if ssl
temp = serversock.recv(19)
clientsock.sendall(temp)
if(temp[15] == '\x01'):
Like you can see we just pass through the initial packet and then just check the response packet for the ‘SSL’ byte before we start intercepting. The output is pretty boring, since everything is saved to the file ‘output.pcap’:
sudo ./rdps2rdp_pcap.py
waiting for connection...
('...connected from:', ('10.50.0.123', 1044))
waiting for connection...
Intercepting rdp session from 10.50.0.123
some error happend
some error happend
You can ignore the errors, that’s just me being lazy for this POC. The output is saved in ‘output.pcap’ which you can then open with wireshark or further process to extract all the key strokes. If you want to play around with the POC you can find it on my github as usual. If you plan on extracting the key strokes make sure you look for the key scan codes and not for the hex representation of the character that the victim typed. In case you are wondering, yes , extracting the key strokes is left as an excersise for the user :)
DiabloHorn 
I do not know, sorry. I have not investigated what the correct configuration should be on Windows 7.
If the the RDP client is win-XP, the python script is working well and the connectios is established.
I don’t use NLA-network level auth.
Hhmmm, what do you think about, where is the problem? Why doesn’t work on win-7?
Hi,
It seems you are having the same problem I had when developing this POC. For some reason I can’t explain the RDP client still does NLA, if you look at the server response in wireshark you’ll see that it’s NOT 0x02.
To get it to work I had to connect with a XP RDP client.
RDP server: 2k8r2 up-to-date 192.168.1.138
MITM: Kali 1.06 apt-get update/upgrade 192.168.1.110
RDP client: win7 up-to-date 192.168.1.111
The firewal is disabled on all machines. I use vmware workstations and every machine is the same subnet and vlan. Every machine ping each others, so network connections looks like good :)
MSTSC on win7 O/S and connect to 192.168.1.138 (RDP server). is working well. First I have to fill username/password and after I see in the log: “Securing remote connection” and get a RDP server self signed certificate. After I click “yes”, the rdp session is established.
This is the rdp server settings:
Connection Type: Microsoft RDP 7.1
Transport: TCP
Security layer: SSL (TLS 1.0)
Encryption level: High
Not Enable: Allow connections only from computers running Remote Desktop with Network Level Authentication.
On System properties I enable this option for the remote desktop:
Allow connections from computer running any version of Remote Desktop (less secure)
So I made the live-environment, start the testing. Start kali and put this to the console:
python ./rdps2rdp_pcap.py -r 192.168.1.138:3389
On win7 client start mstsc and connect to Kali – 192.168.1.110
I fill the username/password credentials on win7 (RDP client) and I am waiting for a very-very long time, but nothing happened. MSTSC write: “securing remote connection”, but the certificate not coming.
This is the log file on Kali:
root@kali:~/Desktop/RDP-mitm# python ./rdps2rdp_pcap.py -r 192.168.1.138:3389
waiting for connection…
(‘…connected from:’, (‘192.168.1.111’, 1120))
waiting for connection…
Passing through 192.168.1.111
some error happend
some error happend
Hi Thomas,
It seems that you are trying to perform a MITM attack on a RDP connection which does not use SSL. In your output the following line appears:
Passing through 192.168.1.111
That means that it either is a ‘old’ RDP protocol client connection or that the RDP client uses NLA. In both cases my tool doesn’t support it.
If I remember correctly cain&abel supports MITMen ‘old’ RDP protocol connections. RDP clients using NLA can not be MITMed afaik.
SSL intercept doesn’t work:
root@kali:~/Desktop/RDP-mitm# python ./rdps2rdp_pcap.py -r 192.168.1.138:3389
waiting for connection…
(‘…connected from:’, (‘192.168.1.111’, 1091))
waiting for connection…
Passing through 192.168.1.111
some error happend
(‘…connected from:’, (‘192.168.1.111’, 1092))
waiting for connection…
ssl intercept doesn’t work.