Metasploit Tips - reverse_https vs reverse_tcp payloads

In this video we will exploit a MS17-010 vulnerable computer, but instead of using the classic "reverse_tcp" payload, we will use the "reverse_https" payload.

There are two main features which make the reverse_http and reverse_https payloads very useful:

1. These payloads are using http/https types of traffic and protocol inspecting firewalls usually allow http/https traffic while they might block other types of traffic. In addition, these payloads use the WinInet API and will leverage any proxy or authentication settings that the user has configured for Internet access.
2. These payloads deal well with cases when the compromised target has spotty Internet access. If the connection between "victim" and the "attacker" machine drops, then the payload will keep trying reconnecting back to the "attacker" computer.

In the video we will exploit the target computer, then we will drop the Meterpreter session by interrupting network connectivity. Then we will see how it is possible to get the Meterpreter session reconnected back to our Kali machine.

The majority of the commands used in this video should be familiar from my previous videos. I'll just mention a few more details in regards to a few commands:
a) When configuring the multi handler module; exploit -j -z will run the exploit as a job (-j option) and will prevent session interaction after successful exploitation (-z option)
b) When configuring the multi handler module; set exitonsession false will keep the exploit running after a session was established (In this way multiple sessions can be established with a single multi handler exploit)
c) The detach command will detach a Meterpreter session, if the session was established via reverse_http or reverse_https payloads. This command cannot be used if reverse_tcp payload was used.

There are a number of advanced payload settings that control various timings for "reverse_http" and "reverse_https", as it can be seen in the picture below:

By default, a session will be forcibly shut down after one week (604800 seconds). If you want to keep a session indefinitely, then set the SessionExpirationTimeout advanced setting to 0 (zero).
Also, by default, an orphaned session (no activity) will be killed after 5 minutes (300 seconds). To change this behavior and keep the session indefinitely, then set the SessionCommunicationTimeout advanced setting to 0 (zero).


  1. since i set SessionExpirationTimeout & SessionCommunicationTimeout to 0 the session will instantly die. Also -1 does not work o.O

  2. The next step to figuring out how often to replace your copier is to figure out how bad your copier woes are and when they started happening. photostat machine


Post a comment

Popular Posts

MS17-010 Vulnerability - Using EternalBlue exploit module in Metasploit

Generating shellcode - using msfvenom to generate a binary payload

MS17-010 Vulnerability - Scanning using Metasploit on KALI Linux