2 min read
July 29, 2019

Meterpreter and HTTPS - TLSv1 Issues

While playing around with NTLMRelayx (part of an upcoming post) on various Windows VMs, I found I was having trouble getting a reverse Meterpreter connection over HTTPS from a Windows 7 machine to a fully updated Kali box. The problem was happening with both staged and non-staged payloads. I had no issues from Windows 8 or Windows 10 machines using the same executable payload so I loaded up Wireshark to see what was going on.

Red boxes are the attacker's IP, grey boxes are the Win7 machine

It looks like the Windows 7 machine tried to establish a TLSv1 connection to the Kali machine and Kali said 'GTFO with that nonsense'.

This was on Windows 7 Pro SP1 without any internet access and thus, no updates applied.

Results of 'winver'

The workaround

I googled around and eventually found this link.

Edit /etc/ssl/openssl.cnf and change 2 lines. Here are the lines and their default values:

Change MinProtocol to 'None' and CipherString to 'DEFAULT'.  

After these changes, I was able to successfully get a Meterpreter connection over HTTPS from the Windows 7 machine.

A better solution (for a home lab anyway)

Even though my Kali VM is isolated and not used as a server, I don't like the idea of downgrading to TLSv1 when there have been multiple vulnerabilities found in it. A bit more googling around and I found this - there's a link to download an "easy fix" or you can manually change your registry. I opted to run the easy fix, reverted my openssl.cnf back to TLSv1.2 and now all is well with Meterpreter over HTTPS:

I could just update the Windows 7 machine but I'm opting to keep my Windows VMs off the internet for now.


You would hope that any remaining Windows 7 machines out in the wild would be updated to some extent but realistically that is simply not the case. This may be one of the few times that updating a Windows machine would make life less difficult for an attacker.