Jump to content
Lux Æterna

Packet Squirrel wiki repository

Recommended Posts

Hey @Sebkinne, any plans on making a PS wiki repo? I was meaning to write a chapter on how to seamlessly expose a LAN segment with OpenVPN. It's a feature I've been using for a long time with small OpenWRT devices (ZSUN sticks, WT3020F, MR3020 etc) and it's awesome for remote management access, as you can seamlessly access the target subnet without having to forward/proxy every single IP/port combination.

Share this post


Link to post
Share on other sites

I believe this is in the works - though it sounds like there's going to be a single point of information for all devices, or something along those lines.

  • Upvote 1

Share this post


Link to post
Share on other sites

Thank you, it makes sense seeing the new layout.
I didn't think my guide warranted a brand new payload, maybe a PR of the existing one?
I'll see when I get my PS in the mail :)

Share this post


Link to post
Share on other sites

Hey Darren,
although it's pretty simple I admit it took me some trial and error to get it working, but now that I did I can manage 5+ networks from home without an issue.
It basically boils down to pushing routes to other VPN clients while specifying which client will actually be the router, and a little bit of iptables magic of course.
A word of caution: since we're going to push routes to your computer and 90% of common subnets are either 192.168.0.0/24 or 192.168.1.0/24 I advise you change your home/most used network to something a bit more uncommon, like 192.168.57.0/24, as to avoid overlapping.
I'm going to assume an OpenVPN server is already set up and running.
So, let's say that my home network is 192.168.57.0/24 and I want to use a PS to manage target network 192.168.0.0/24. Let's also assume my VPN subnet is something like 10.9.20.0/24, and that your computer and PS when connected to the VPN have the IPs 10.9.20.4 and 10.9.20.8 respectively.
On my VPN server I need to create a new folder to contain client specific directives.

mkdir /etc/openvpn/ccd


In this folder I'm going to create a file that's named exactly like the client name I used when I created a certificate for the PS (this is important, if you don't otherwise it's not going to work). I'm going to assume it was packetsquirrel
 

vi /etc/openvpn/ccd/packetsquirrel

In this file I'm going to insert this line
 

iroute 192.168.0.0 255.255.255.0

This tells OpenVPN that the route 192.168.0.0/24 is going to flow through this specific client.
Then you need to edit your openvpn's server.conf

client-to-client						# allows VPN clients to communicate with each other
client-config-dir /etc/openvpn/ccd/		# specifies the folder we created earlier as client-config-dir
push "route 192.168.0.0 255.255.255.0"	# pushes the route 192.168.0.0/24 to every connected client
route 192.168.0.0 255.255.255.0			# adds this route to the OpenVPN server itself

Once you've done that restart your OpenVPN server.
If everything went smoothly you should be able to SSH into the PS directly with "ssh root@10.9.20.8".
Do that, and from inside the PS run this command:

iptables -t nat -A POSTROUTING -o eth1 -s 10.9.20.0/24 -j MASQUERADE

(Warning: I'm not sure this was the only needed IPTables rule, I'm going to check again once I get my hands on the PS, as my existing routers are a forest of rules :) )
Again if everything went smoothly you should be able to seamlessly reach every device on the target's LAN (eg: 192.168.0.1 for the router).

And that's pretty much it.
Sadly the last part is a bit fuzzy as it's been a while since I set it up, but I'm going to write an in-depth guide once I receive my PS.
Hope this helped!

  • Like 1
  • Upvote 1

Share this post


Link to post
Share on other sites
18 minutes ago, taswanita said:
  • very complete thanks mate

You're very welcome :) I'll make sure to update it asap. It's something I hold particularly dear because it helped me maintain access so many times before.
It's also one of the reason I particularly like OpenWRT: extremely small devices are enough to backdoor an entire network.

Share this post


Link to post
Share on other sites

Wow - this is fantastic. I'll attempt to duplicate this with the Packet Squirrel ASAP. I've done similarly with the LAN Turtle on Hak5 using OpenVPN-AS and, I wouldn't say it was a nightmare, but it was nowhere near as straight forward as your write-up. Thank you!

The only difficulty I see is that the OpenVPN server needs prior knowledge of the remote network's IP scheme -- in your example 192.168.0.0/24.

In the event that one is dropping a Packet Squirrel on a network as part of a penetration test through means of social engineering, prior knowledge of the IP scheme may not be available.

I wonder in that case if a script on the Packet Squirrel end could then enumerate the LAN before establishing the OpenVPN connection, and then pass over its own config to be used. Perhaps then "re-dialing" if need be.

  • Upvote 1

Share this post


Link to post
Share on other sites
1 minute ago, Darren Kitchen said:

I wonder in that case if a script on the Packet Squirrel end could then enumerate the LAN before establishing the OpenVPN connection, and then pass over its own config to be used. Perhaps then "re-dialing" if need be.

That's definitely something I considered doing in the past, but it really hasn't been a problem: as long as you have the client-to-client directive in your OpenVPN server and the network has DHCP you'll always be able to ssh in the PS, check the WAN subnet and course-correct.
I own a flock of ZSUN sticks that I use exactly for this purpose, and customize them depending on the client/engagement: plug them somewhere, configure their client mode, take note of the subnet, edit the conf files accordingly and bam, free backdoor as long as the AP stays up.

  • Upvote 1

Share this post


Link to post
Share on other sites

 

7 minutes ago, Lux Æterna said:

That's definitely something I considered doing in the past, but it really hasn't been a problem: as long as you have the client-to-client directive in your OpenVPN server and the network has DHCP you'll always be able to ssh in the PS, check the WAN subnet and course-correct.

 

Good call. In that case said auto-routing script could live on the VPN server side.

As it turns out this same conundrum was sorted on a LAN Turtle thread regarding the OpenVPN-AS method I had previous stated

 

  • Upvote 1

Share this post


Link to post
Share on other sites
45 minutes ago, Darren Kitchen said:

Wow - this is fantastic. I'll attempt to duplicate this with the Packet Squirrel ASAP. I've done similarly with the LAN Turtle on Hak5 using OpenVPN-AS and, I wouldn't say it was a nightmare, but it was nowhere near as straight forward as your write-up. Thank you!

Also, funnily enough I remember that episode because I was looking for a more "streamlined" way to do exactly this.
Sadly OpenVPN AS is too limited for my needs, and in the end the Unix just-read-the-man-page-and-do-it-from-the-cli way always wins in the long run.

20 minutes ago, Darren Kitchen said:

 

 

Good call. In that case said auto-routing script could live on the VPN server side.

As it turns out this same conundrum was sorted on a LAN Turtle thread regarding the OpenVPN-AS method I had previous stated

 

Much better idea IMHO. I always try to keep my devices from calling too much home because I always assume they'll be discovered and I definitely don't want to give away information about my infrastructure in case of closer inspection; server -> client, however, it's preferable because it's much harder to detect, especially if you don't keep logs on the device.

Edited by Lux Æterna

Share this post


Link to post
Share on other sites
5 hours ago, Darren Kitchen said:

Good call. In that case said auto-routing script could live on the VPN server side.

The only downside I could think of is that automating the process could lead to subnet overlapping on your client PC if you're not careful and double check every time.
Say you need to plant the packet squirrel on a 192.168.0.0/24 and your home network is 192.168.57.0/24: unless you start the OpenVPN client only when you know you're on an "unconventional" subnet you're fine, but if you want to bring your laptop to, say, a Starbucks or a new network altogether you may find it shares a subnet (192.168.0.0/24) with the target network, and with your computer unable to connect properly to the internet. So yeah maybe a client-side discovery script with a big disclaimer on where to NOT launch VPN would be a good idea.
A nice workaround (that I'm going to test immediately) is to push the OpenVPN routes with the highest possible metric: worst case scenario you can't access the remote subnet, but you'll still able to connect  to the internet and the Packet Squirrel.

Share this post


Link to post
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.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...