search

ctxis / RDP-Replay

Replay RDP traffic from PCAP
Apache License 2.0
183 stars 61 forks source link

Unable to play pcap #7

Open mertsarica opened 8 years ago

mertsarica commented 8 years ago

Well let me explain you the steps that I followed one by one;

In Windows 7 Enterprise Service Pack 1 32 bit, I ran cmd.exe as an Administrator and then ran mimikatz.exe with psexec -s parameter with folowing commands as shown below. C:\Users\IEUser\Desktop\Win32>PsExec.exe -s C:\Users\IEUser\Desktop\win32\mimika tz.exe

PsExec v2.11 - Execute processes remotely Copyright (C) 2001-2014 Mark Russinovich Sysinternals - www.sysinternals.com

mimikatz 1.0 x86 (RC) /* Traitement du Kiwi (Aug 26 2012 12:48:16) */ // http://blog.gentilkiwi.com/mimikatz

mimikatz # privilege::debug Demande d'ACTIVATION du privilège : SeDebugPrivilege : OK

mimikatz # crypto::patchcapi Patterns CRYPT_EXPORTABLE | CRYPT_ARCHIVABLE et CRYPT_ARCHIVABLE trouvés ! Patch CRYPT_EXPORTABLE | CRYPT_ARCHIVABLE : OK Patch CRYPT_ARCHIVABLE : OK

mimikatz # crypto::patchcng Service : CNG Key Isolation Recherche des patterns dans : ncrypt.dll@pid(476) Patch ncrypt.dll@pid(476) : OK

mimikatz # crypto::exportCertificates CERT_SYSTEM_STORE_LOCAL_MACHINE "Remote De sktop" Emplacement : 'CERT_SYSTEM_STORE_LOCAL_MACHINE'\Remote Desktop

Then I installed Win32OpenSSL-1_0_2h on Windows 7 and then converted pfx to pem.

C:\OpenSSL-Win32\bin>openssl pkcs12 -in "CERT_SYSTEM_STORE_LOCAL_MACHINE_Remote Desktop_0_IE10Win7.pfx" -nodes -out x509.pem WARNING: can't open config file: /usr/local/ssl/openssl.cnf Enter Import Password: MAC verified OK

Then I installed Wireshark-win32-2.0.4 to Windows 7, sniffed the traffic with filter "tcp.port == 3389" and then connected to that Windows 7 from Windows 8.1 via RDP (mstsc).

Then I copied sniffed traffic (Wireshark - save as - Wireshark/tcpdump - rdp.pcap) to Ubuntu 14.04 (which I successfully played your demo1.pcap) with the x509.pem of Windows 7 and then tried to play with rdp_replay.

root@ubuntu:~/Desktop/RDP-Replay-master/replay# ./rdp_replay -r rdp.pcap -p x509.pem --no_cksum root@ubuntu:~/Desktop/RDP-Replay-master/replay#

It shows nothing. So any idea which step is wrong ? If you'd like to get pcap, pem file and pfx, I can send it to you.

Regards,

SteveWare commented 8 years ago

Please check that you recorded the PCAP correctly. I would expect to see some message to be output if the replay software finds a valid TCP stream on port 3389.

mertsarica commented 8 years ago

How did you record your demo1.pcap ? With wireshark or tcpdump ? With filter or not ?

SteveWare commented 8 years ago

I recorded with wireshark, no filter.

mertsarica commented 8 years ago

Weird maybe I should record my steps and upload it to youtube and show to you.

SteveWare commented 8 years ago

On you Ubuntu box, run this tcpdump -r rdp.pcap | head so that I can check that the pcap has data, and the ports are OK.

mertsarica commented 8 years ago

root@ubuntu:~/Desktop/RDP-Replay-master/replay# tcpdump -r rdp-ssl.pcap | head reading from file rdp-ssl.pcap, link-type EN10MB (Ethernet) 05:03:32.608446 IP 192.168.92.1.5409 > 192.168.92.139.3389: Flags [S], seq 2284118509, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 05:03:32.608573 IP 192.168.92.139.3389 > 192.168.92.1.5409: Flags [S.], seq 2474964570, ack 2284118510, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 05:03:32.608806 IP 192.168.92.1.5409 > 192.168.92.139.3389: Flags [.], ack 1, win 256, length 0 05:03:32.609681 IP 192.168.92.1.5409 > 192.168.92.139.3389: Flags [P.], seq 1:20, ack 1, win 256, length 19 05:03:32.614554 IP 192.168.92.139.3389 > 192.168.92.1.5409: Flags [.], ack 20, win 256, length 0 05:03:32.614688 IP 192.168.92.139.3389 > 192.168.92.1.5409: Flags [P.], seq 1:20, ack 20, win 256, length 19 05:03:32.659313 IP 192.168.92.1.5409 > 192.168.92.139.3389: Flags [.], ack 20, win 256, length 0 05:03:33.787906 IP 192.168.92.1.5409 > 192.168.92.139.3389: Flags [P.], seq 20:207, ack 20, win 256, length 187 05:03:33.811303 IP 192.168.92.139.3389 > 192.168.92.1.5409: Flags [P.], seq 20:1183, ack 207, win 255, length 1163 05:03:33.817059 IP 192.168.92.1.5409 > 192.168.92.139.3389: Flags [P.], seq 207:341, ack 1183, win 252, length 134

mertsarica commented 8 years ago

Do you want me to send you pcap and extracted key ?

SteveWare commented 8 years ago

You might want to check you have the correct key. Open the pcap in wireshark, and decode as SSL. You want to look at the server's certificate message: Handshake - certificates - certificate - signedCertificate - subjectPublicKey Compare that with the public key from the pem file openssl rsa -in x509.pem -inform pem -outform der -pubout | od -tx1

I still don't know why you get no output from rdp_replay.

SteveWare commented 8 years ago

I just remembered that it's likely to be using DHE to exchange the session key. This does not use the private key, and so we do not have a way to unlock the crypt. You can check this be looking at the "Server Hello" message, and seeing what cipher suite is chosen.

mertsarica commented 8 years ago

I ll check it and let you know. But if so what is the workaround for DHE case ? Did you disable that ?

SteveWare commented 8 years ago

There is no way to use that PCAP. When I set this up the (Linux) client offered several DHE options, but the (Windows 7) server chose TLS_RSA_WITH_AES_128_CBC_SHA, so I didn't need to force anything. If this is the problem you will need to persuade either the client not to offer DHE, or the server not to choose it. Google may be your friend here.

mertsarica commented 8 years ago

Thanks, I ll try that and let you know about the result.

mertsarica commented 8 years ago

Yo are right, it is DH. dh

SteveWare commented 8 years ago

Microsoft changed the defaults about 15 months ago, and MS servers now seem to prefer DH. Good that we know why it is not working.

mertsarica commented 8 years ago

I have successfully decrypted ssl with wireshark but ./rdp_replay -r rdp-ssl-nodh.pcap -p x509.pem -t 3389 --no_cksum still shows nothing :/

SteveWare commented 8 years ago

Do you get any output at all from rdp_replay? I would expect something like

RDP SSL MODE Requested by server!!
SSL private key found.

Or even

RDP SSL MODE Requested by server!!
SSL-ERROR: No matching private key found

If you get nothing is might indicate that no TCP stream is found for some reason. Can you dump the first few packets (like you did above) of this new PCAP, please?

mertsarica commented 8 years ago

Nope, it shows nothing. Maybe you would like to download the pcap with pem file and take a look :) https://www.mertsarica.com/priv8/rdp-replay-sample.zip

By the way here is the output of head.

root@ubuntu:~/Desktop/RDP-Replay-master/replay# tcpdump -r rdp-ssl-no-dh4.pcap | head reading from file rdp-ssl-no-dh4.pcap, link-type EN10MB (Ethernet) 11:47:35.478189 IP 192.168.92.1.8247 > 192.168.92.139.3389: Flags [S], seq 4060876918, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 11:47:35.478444 IP 192.168.92.139.3389 > 192.168.92.1.8247: Flags [S.], seq 1676525805, ack 4060876919, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 11:47:35.478659 IP 192.168.92.1.8247 > 192.168.92.139.3389: Flags [.], ack 1, win 256, length 0 11:47:35.480120 IP 192.168.92.1.8247 > 192.168.92.139.3389: Flags [P.], seq 1:20, ack 1, win 256, length 19 11:47:35.486674 IP 192.168.92.139.3389 > 192.168.92.1.8247: Flags [.], ack 20, win 256, length 0 11:47:35.486836 IP 192.168.92.139.3389 > 192.168.92.1.8247: Flags [P.], seq 1:20, ack 20, win 256, length 19 11:47:35.538157 IP 192.168.92.1.8247 > 192.168.92.139.3389: Flags [.], ack 20, win 256, length 0 11:47:37.029857 IP 192.168.92.1.8247 > 192.168.92.139.3389: Flags [P.], seq 20:207, ack 20, win 256, length 187 11:47:37.039264 IP 192.168.92.139.3389 > 192.168.92.1.8247: Flags [P.], seq 20:852, ack 207, win 255, length 832 11:47:37.043605 IP 192.168.92.1.8247 > 192.168.92.139.3389: Flags [P.], seq 207:533, ack 852, win 253, length 326

rdp

rdp2

SteveWare commented 8 years ago

Looks like there is a real problem here. Will look into it.

SteveWare commented 8 years ago

There is a problem with the --no_cksum option. It turns out that this only turns off checking of the TCP checksum. Wierdly this has been fine up to now. I have a local fix for this that I will push soon.

The PCAP has 2 streams. Stream 0 terminates early without really establishing a session. This is the stream that rdp_replay will be picking up. Use -t 8250 to select the second stream.

I cannot get the second stream (TCP stream 1) to decrypt.

Looking at the SSL debug output from processing frame 25 (from TCP stream 1) (the first encrypted message)

Ciphertext[48]:
| 6c 80 87 fe d1 1e 4d a5 b6 2d 30 2a 01 b3 74 01 |l.....M..-0*..t.|
| 69 42 88 a0 f4 eb 8d b1 a9 7c bb ef ac c0 b1 bc |iB.......|......|
| 30 51 46 4a 22 96 6a f1 c1 6e b2 bd 02 99 a7 84 |0QFJ".j..n......|
Plaintext[48]:
| f6 8b 64 96 d0 cf 99 d1 8f d5 d4 e9 0b 8c 03 56 |..d............V|
| 27 07 92 1a 00 95 bf 47 65 d9 89 19 e9 4e 8f d6 |'......Ge....N..|
| 11 ca 96 0c 58 37 9e c8 f1 87 d9 fc e3 c6 8a 06 |....X7..........|
ssl_decrypt_record found padding 6 final len 41
checking mac (len 21, version 301, ct 22 seq 0)
tls_check_mac mac type:SHA1 md 2
Mac[20]:
| 06 b9 ff eb 53 39 ed 0d f9 3c 29 be d5 a9 28 f4 |....S9...<)...(.|
| ee 08 7e 00                                     |..~.            |
ssl_decrypt_record: mac failed
dissect_ssl3_handshake iteration 1 type 108 offset 278 length 8423422 bytes, remaining 326

This shows that my wireshark cannot decrypt this stream. The debug output does show what looks like a valid pre master secret recovery. I'm using Version 1.10.6 (64-bit) on Ubuntu 14.04. My amended version of of rdp_replay also fails at this point (with SSL: Decrypt failed). Turning off MAC check results in junk data out of the decrypt (as you'd expect).

SteveWare commented 8 years ago

Your wireshark screenshot shows what looks like a good decrypt. What version (and OS) are you using there?

mertsarica commented 8 years ago

Hello,

I use Wireshark v2.0.3 and Wireshark is able to decrypt tcp.stream eq 1 as shown below. At the moment I run Wireshark (viewing sniffed pcap file ) on Windows 7 Enterprise SP 1 64 Bit but pcap was recorded in Windows 7 Enterprise SP 1 32 Bit. (I downloaded that Windows 7 32 Bit from modern.ie)

rdp

SteveWare commented 8 years ago

Looks like the SSL session you have recorded is using a fairly new extension (extension 23: Extended Master Secret), as defined in RFC 7627 (dated Sept 2015)

I have managed to decrypt this session with a new version of wireshark. I will see if I can do anything with the SSL decryption in rdp_replay. At least we now know what the problem is.

mertsarica commented 8 years ago

Great news. So in order to use rdp_replay for now, I have to use Windows 7 SP1 without any update I think, right ?

SteveWare commented 8 years ago

You may be able to use options to turn off this feature. It looks like openssl does not support this option yet, but will in version 1.1 (currently in beta testing). I only had a quick look, so I might be wrong about openssl support for this. I have pushed the fix for the checksum problem.

mertsarica commented 8 years ago

Windows lets you to disable DisableServerExtendedMasterSecret so ithis could be a workaround for rdp_replay issue. ( [https://support.microsoft.com/en-us/kb/3081320] )

mertsarica commented 8 years ago

I've tried that but no success. rdp3

SteveWare commented 8 years ago

If you make the latest pcap available I'll take a look when I get a chance.

mertsarica commented 8 years ago

Please let me know after you successfully download it. https://www.mertsarica.com/priv8/rdp-ssl-no-dh5.zip Server Hello does not contain extended master secret after I changed that value in the registry. rdp4

SteveWare commented 8 years ago

I have the file. If you run with -t 16757 it will get the second stream. By default it will process the first stream on port 3389. This is a short session, and not the one you are interested in. Having said that, running the stream on port 16757 causes a segmentation fault. Ooops. This might take a while, but I will look into this at some point. It's probably negotiating options that are not supported or something similar.

mertsarica commented 8 years ago

Good luck then :)

yanncam commented 5 years ago

Hello,

I am currently experiencing exactly the same problem:

I tried rdp_replay compiled with all dependencies on the latest Kali Linux, on an Ubuntu 16.04 and I even reinstalled an Ubuntu 14.04 in accordance with this issue, without resulting.

The demo1.pcap with the keydemo1.pem works perfectly, but not my own pcap ...

I execute the following command and get the associated output:

$ ./rdp_replay -r mypcap.pcap -p private.key --no_cksum -o record.avi
SSL RDP MODE Requested by server !!
SSL private key found.
$

The tool gives me the hand only after several tens of seconds (so I guess it works). Only, with or without the -o record.avi option, I do not have video rendering at all times displayed or saved.

This issue dates back to 2016, do you have new elements on this subject?

Thanking you,

yuanLink commented 3 years ago

Hi @yanncam , I also have same problem, and I found that because my pcap contain three different session connection requst: wireshark And when I using the rdp_replay firstly, it will not work. And I found the demo.pcap only contain the final request, so I just save the third requests to pcap, and finally it work well