Open Wireshark and go to Edit > Preferences > Protocols > SSL >Edit and do the exact setup you can see. If the malware is using client SSL certificate validation then you might need to extract the client certificate and key from the malware and use that on your MITM server as the client certificate and key for your scriptįrom personal experience in the field I can say that most of the times the malware just uses SSL without even setting the option to verify that the certificate is valid, so you shouldn't worry that much about needing to modify or reverse engineer the sample to decrypt the traffic, you might need to do that to understand what it's sending as the malware might obvuscate the data sent (re-encrypting it with some embeded key or making the traffic look legit). First you need the private key used by you server.If the malware is using SSL certificate pinning (aka verifing that the server uses a specific certificate) then you might need to to some reverse engineering in order to find out where you should put your certificate in the executable of the malware.If the SSL certificate of the C2 is valid and you want the first alternative, then you want to add a certificate authority on the system running the malware that has signed the key that your server is using.They have a tutorial on their docs page about it, I personally recommend using mitmweb, you can play with the protocol in a browser and replay requests with different arguments to see what happens.
If you suspect the malware to use HTTPS than you can setup mitmproxy on the second system and make it a gateway and run it in transparent mode to intercept the packets on the fly.
Using SSLKEYLOGFILE should work if the applications generating the TLS traffic use a TLS library that observes that environment variable and emits the correct keying material into the file. Step 1: Client Hello Step 2: Server Hello Step 3: Certificate, Server Encryption Key, and Server Hello Done Step 4: Client Encrypted Key, Change Cipher Spec, and Finished Step 5: Change Cipher Spec And Finished TCP Three-Way Handshake Protocol: In HTTP, the TLS handshake will happen after the completion of a successful TCP handshake. You can use fakenet-ng to redirect the connection on the system that is running the malware. Wireshark decryption of TLS traffic works, if it's provided with the correct keying material. Using the script you can then just pipe the decrypted data to one of the C2 servers and log the data sent and received into a file. Then run the Wireshark and open the Preferences -> Protocols -> SSL, where we put the path to the SSL keys log file into the (Pre)-Master-Secret log filename. If you know the ip addresses of C2s you can add a route on the system to modify the destination of the traffic to a localhost or, better yet, another system on the network that has a script made by you that is listening on the same port as the C2 server using it's own SSL key and certificate. I tried to include the stunnel pem file in Wireshark but without success.From what I understand, SSLKEYLOGFILE is an environment variable, problem is, programs usually need to be coded to deal with environment variables, thing that no malware creator will do since they don't want their C2 traffic to be intercepted.Ī solution would be to use a MITM setup, here are some ideas I use at my job to do this sort of thing: My stunnel client conf is as follow Ĭert = C:/whatever/stunnel/config/stunnel.pem Would it still be possible to decrypt the traffic knowing only the client's RSA keys? And where could I find them? You can check for this in the handshake packet. Click the + button to add a key: Then add the RSA private key key-20180317-161753.pem. http is the protocol carried inside the SSL/TLS session - c:\tls\keyout.pem is the name of the file which includes the converted private key - c:\tls\debug2.txt is the name of the file which includes information about the. 443 is the TCP port at the server side. In that case Wireshark cannot decipher SSL/TLs with a private key. These are the steps to follow: Go to preferences: Search for the TLS protocol, and edit the RSA Keys list. This is the server using the certificate that we extracted the private key from. In this setup, I only have client RSA keys. 1 Answer Sorted by: 5 There is strong possibility that a Diffie-Hellman (DH) key exchange is being used here. I used to decrypt TLS 1.2 RSA traffic by using the server pem file.
I can confirm the cipher used is from the RSA family (TLS_RSA_WITH_AES_256_GCM_SHA384). Thus, I captured traffic between the MITM client and the webserver.
The traffic between the MITM client and the webserver could be decrypted with the RSA keys method as the webserver allows the use of RSA ciphers and the MITM client is configured to use RSA ciphers only. The traffic between the app and the MITM server cannot be decrypted simply with RSA cipher as the app is not accepting such cipher anymore. I am using stunnel as a MITM to decrypt TLS traffic in between an app and its web server.
0 kommentar(er)
