LAN Turtle + OpenVPN != Meterpreter Reverse Shells

[colejustin]

Building on the idea of having access to all resources in a target network using OpenVPN, is there a way to catch reverse shells through the LAN Turtle coming back to Metasploit that is connected to the same VPN?

Scenario:  I have planted the LAN Turtle in a client's network for a pen test engagement.  I can ping targets in the client network without any issues, even RDP to some of them.  But if I try to use an exploit from Metasploit with a meterpreter reverse shell payload, I don't get the shell back.  I'm guessing this is because the clients in the target network are not aware of the route back to my Kali box that sits on the VPN.

I've also tried to set the internal IP address of the LAN Turtle (that it picks up from the client's DHCP server) as the LHOST, but I don't think the LAN Turtle knows what to do with the reverse connection once it gets it.

Is there some sort of iptables trickery that I can use to forward to reverse shell back to my Kali box that's connected to the VPN?  Or is there another way altogether to get the reverse shell back?

[jafahulo]

On 4/27/2017 at 2:02 PM, colejustin said:

Building on the idea of having access to all resources in a target network using OpenVPN, is there a way to catch reverse shells through the LAN Turtle coming back to Metasploit that is connected to the same VPN?

Scenario:  I have planted the LAN Turtle in a client's network for a pen test engagement.  I can ping targets in the client network without any issues, even RDP to some of them.  But if I try to use an exploit from Metasploit with a meterpreter reverse shell payload, I don't get the shell back.  I'm guessing this is because the clients in the target network are not aware of the route back to my Kali box that sits on the VPN.

I've also tried to set the internal IP address of the LAN Turtle (that it picks up from the client's DHCP server) as the LHOST, but I don't think the LAN Turtle knows what to do with the reverse connection once it gets it.

Is there some sort of iptables trickery that I can use to forward to reverse shell back to my Kali box that's connected to the VPN?  Or is there another way altogether to get the reverse shell back?

I'm not a genius in the field, but yes, I'd assume that there would have to be some iptables trickery involved.

Either that or port forward the traffic through your LT to the port on your kali box?

 

lmk if you get it working!

[wutanglan]

On 4/27/2017 at 3:02 PM, colejustin said:

Building on the idea of having access to all resources in a target network using OpenVPN, is there a way to catch reverse shells through the LAN Turtle coming back to Metasploit that is connected to the same VPN?

Scenario:  I have planted the LAN Turtle in a client's network for a pen test engagement.  I can ping targets in the client network without any issues, even RDP to some of them.  But if I try to use an exploit from Metasploit with a meterpreter reverse shell payload, I don't get the shell back.  I'm guessing this is because the clients in the target network are not aware of the route back to my Kali box that sits on the VPN.

I've also tried to set the internal IP address of the LAN Turtle (that it picks up from the client's DHCP server) as the LHOST, but I don't think the LAN Turtle knows what to do with the reverse connection once it gets it.

Is there some sort of iptables trickery that I can use to forward to reverse shell back to my Kali box that's connected to the VPN?  Or is there another way altogether to get the reverse shell back?

Think of the turtle and Open VPN as getting a foothold on the target network itself, NOT exploiting actual machines. Now talking in terms of metasploit / meterpreter, these payloads can be leveraged, but doing so through Open VPN is rather not a good option imo -> unless you configure the payload(s) specifically to speak through the tap0 interface of the turtle, but even this would require the iptables trickery that was mentioned and likely involve altering routes which would contradict the whole white box pen testing scenario you mentioned.

How did you go about configuring the payload(s), and were you sure the machines you ran them on were vulnerable and didn't get tripped by AV ? Elaborate more on what you did there and we can see if we can help.

I'm sure there are iptables we can conjure on the turtle or surrounding our VPN, but to make this much simpler what you can do to get a reverse shell outside of the turtle to your machine is open up ports yourself either to a droplet through DDNS or to your local machine through the internet, although this may be noisy to local network admins on the pen-test site.

Other than the networking stuff we mentioned, I would look more into the payload(s) you're using and how the target machine(s) respond to them or failed to respond in this case.

 

[GrineUlf]

As said by @wutanglan, there is not enough information available about your situation to help precisely, and probably iptables trickery can help. But if you own the server that you have the VPN connection on you could also use a high range port that doesn't trip for example windows firewall on the target machine, and use their own internet connection to connect directly to your server.

However, this might indeed be noisy (depending on what you actually are doing) as well as possibly unencrypted. I personally use a cloud server to do most of my pentest engagements, and works fine ?