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.
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.
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.
Conclusion
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.