Unable to play pcap

[mertsarica]

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

• IE10Win7
  Container Clé : TSSecKeySet1
  Provider : Microsoft Strong Cryptographic Provider
  Type : AT_KEYEXCHANGE
  Exportabilité : NON
  Taille clé : 2048
  Export privé dans 'CERT_SYSTEM_STORE_LOCAL_MACHINE_Remote Desk
  top_0_IE10Win7.pfx' : OK
  Export public dans 'CERT_SYSTEM_STORE_LOCAL_MACHINE_Remote Deskt
  op_0_IE10Win7.der' : OK

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]

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]

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

[SteveWare]

I recorded with wireshark, no filter.

[mertsarica]

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

[SteveWare]

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]

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]

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

[SteveWare]

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]

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]

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

[SteveWare]

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]

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

[mertsarica]

Yo are right, it is DH.

[SteveWare]

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]

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]

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]

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

[SteveWare]

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

[SteveWare]

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]

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

[mertsarica]

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)

[SteveWare]

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]

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]

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]

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]

I've tried that but no success.

[SteveWare]

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

[mertsarica]

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.

[SteveWare]

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]

Good luck then :)

[yanncam]

Hello,

I am currently experiencing exactly the same problem:

• I have a pcap which decrypts itself without problem in Wireshark with the private.key (I can see the TLSv1 handshake, the CredSSP frames, then the TPKT / RDP / COTP streams)
• I do not have an extension in the Server Hello handshake
• Negotiated Ciphersuite is TLS_RSA_WITH_AES_128_CBC_SHA (no DH so)
• I only have one stream on port 3389 (so no need for the -t option)

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 key demo1.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]

Hi @yanncam , I also have same problem, and I found that because my pcap contain three different session connection requst:

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