Jump to content

Metasploit No Session Created Vm


Residuum
 Share

Recommended Posts

Hey,

I am looking for an answer regarding metasploit. I try to connect to a remote pc outside my network and somehow therefore I would like to set up a handle on my internal ip, but give my payload the external ip. However I am only seeing the option to set LHOST in which case the handler or the payload gets the wrong ip and setting up a separate handler would blocking my port.

Maybe there is an easier method? to set the server ip of reverse_tcp to my external not directly creating a handler on the same ip....

The following assumptions can be made:

port is correctly forwarded on machine with external ip

payload and exploit are working on target

payload is reverse_tcp

Thanks for the Help

Residuum

Link to comment
Share on other sites

If you have correctly forwarded the right port on your router. Then make sure there is no security essentials running on the target host (eg AV or Firewall).

On the other hand, can you successfully exploit the box from within your network? If you can't, then it could mean that the box is not vulnerable to the exploit.

Edited by Infiltrator
Link to comment
Share on other sites

well there is indeed a possibility to disable the handler:

set DisablePayloadHandler=true

I haven't tried it but it should work. However I thought about it again and the listener jumped back on 0.0.0.0 when using the remote address as lhost, so it should have worked already. The test target runs XP sp2 so it should be exploidable! weird stuff is going on.

Link to comment
Share on other sites

lhost has to be your machines local IP, not your external ISP IP, because once it reaches the router and port forwards to the responding port the router would still probably drop the packet as if it were an anonymous request. It would have to follow the layers it originated and initiated the session from, and since it wasn't originated at the external IP, I think it would probably just drop the traffic if you tried to use that address. Because of this, you would probably need to have the machine running metasploit to be in a DMZ or directly on the internet and not behind NAT.

Meterpreter handles the rest of the session reversing I believe. If you can't get a session, you probably aren't hitting the target directly. Let me ask you this. Is the target machine yours? Because, if it is, you would know it it sits behind a router as well. If you are trying to traverse NAT on both sides of the pond, then more than likely, without a web page exploit to point the XP machine to, you are only hitting the target machines router. The XP machine would need to be sitting directly on the internet or in a DMZ itself if behind a router in order to reach it, or have that XP machine visit a web page hosted by you with the exploit, while listening for responses from the visiting XP machine. This would require setting up something like Apache and DynDNS to serve the page to the XP machine and port forward on your own router so the victim can reach it to be exploited. Again, being in a DMZ on your end would solve a lot of problems.

Metasploit will work over the internet and a reverse shell will work as well, but its probably easier if you put the machine running metasploit in a DMZ by itself so as not to have to worry about port forwarding and NAT traversal. If its sitting directly on the internet connection, then it can respond to anything coming back from the XP machine. If the session still failed, then its probably not vulnerable, either by way of firewall or services turned off on the victim machine.

You could set up a bind shell payload, so the target is just sitting and listening on a port for commands once its exploited. Then you can remote in that way once it has been exploited without having to port forward your router or have the machine sit in a DMZ on your end.

Link to comment
Share on other sites

lhost has to be your machines local IP, not your external ISP IP, because once it reaches the router and port forwards to the responding port the router would still probably drop the packet as if it were an anonymous request. It would have to follow the layers it originated and initiated the session from, and since it wasn't originated at the external IP, I think it would probably just drop the traffic if you tried to use that address. Because of this, you would probably need to have the machine running metasploit to be in a DMZ or directly on the internet and not behind NAT.

Meterpreter handles the rest of the session reversing I believe. If you can't get a session, you probably aren't hitting the target directly. Let me ask you this. Is the target machine yours? Because, if it is, you would know it it sits behind a router as well. If you are trying to traverse NAT on both sides of the pond, then more than likely, without a web page exploit to point the XP machine to, you are only hitting the target machines router. The XP machine would need to be sitting directly on the internet or in a DMZ itself if behind a router in order to reach it, or have that XP machine visit a web page hosted by you with the exploit, while listening for responses from the visiting XP machine. This would require setting up something like Apache and DynDNS to serve the page to the XP machine and port forward on your own router so the victim can reach it to be exploited. Again, being in a DMZ on your end would solve a lot of problems.

Metasploit will work over the internet and a reverse shell will work as well, but its probably easier if you put the machine running metasploit in a DMZ by itself so as not to have to worry about port forwarding and NAT traversal. If its sitting directly on the internet connection, then it can respond to anything coming back from the XP machine. If the session still failed, then its probably not vulnerable, either by way of firewall or services turned off on the victim machine.

You could set up a bind shell payload, so the target is just sitting and listening on a port for commands once its exploited. Then you can remote in that way once it has been exploited without having to port forward your router or have the machine sit in a DMZ on your end.

first thank you for your extensive answer.

I do not agree with you first comment fully. Lets assume you set a up router and forward port 80 to an webhost in you NAT, then you could still access the webhost with only knowing the address of the router. As far as I understood Metasploit, the LHOST belongs to the payload giving it the IP to reach out to. So if you set it to you local nat ip it would never be found.

I am certain hitting it directly with the knowledge of an smb port being open and if it wasn't a coincidence executing it accidentally. I have setup a webpage including a small program I wrote to taking orders from an ftp and shoveling up the result. So I try to move on.....

Your suggestion with the bindshell is intriguing. I ll have to try it :)

Link to comment
Share on other sites

Here is the thing. Even if the target machine was vulnerable, you would at a minimum, get a session. Interacting with it is a whole other story, but if there is no session, then something is failing, either in the port forwarding and networking between the two, or the machine is not vulnerable to exploit you are trying. If it is vulnerable, you should get a session but that doesn't guarantee the ability to use it. For that, you might need something like persistent reverse http or something that proxies the connection and tunnels it back. Although a bind might be easier to implement, like dumping netcat or ncat in a staged payload and have it listening on the target machine.

Just for shits and giggles though, try it from a DMZ, or directly connected to the internet without the router in the scenario. If it works, then you know your configuration for the port forward or other such is at fault. If it still fails, then your victim is either not vulnerable to the exploit and/or payload.

Edited by digip
Link to comment
Share on other sites

In most cases it would be very difficult to exploit a machine that is behind a firewall, unless its completely exposed to the internet or placed in a DMZ your chances would be very slim.

An attacker for example would have to use other techniques to exploit a target. Via drive by download or via PDF exploits. PDF exploits would be the most common method and you can use Metasploit to encode a reverse_shell into your own PDF file, just as suggested by Digip.

Link to comment
Share on other sites

Thanks you all for the replies, I will take a look at the book. I bridged the VM in the network unsuccessfully creating a session with metasploit. So you are probably right that the target is patched.

Did you try exploiting it from within your network or outside?

Link to comment
Share on other sites

Did you try exploiting it from within your network or outside?

I did both. I bridged the VM-Ware directly over my main OS and a second time over my router and disabled all FW's. Further, I set up a test which i could exploit, when the XP firewall was down. So unfortunately remote exploitation even with old OS is not that easy than client sided attacks.

The book Penetration Tester's Guide only gives some good tips finding vulnerabilities on not updated system. But not on a certain System you want to exploit, since most computers do not run telnet, ssh, sql, http etc. I have been using the auxiliary scanners of msf and Nessus, which also provides a lot of informations about possible attack vectors. So I am now looking in arp poisoning and sniffing of traffic to find an entry point.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...