PWNplug - onsite Pen(-)tests, Reverse Shells, and Network Access Control

Tags: #<Tag:0x00007f0ca900a390> #<Tag:0x00007f0ca900a250> #<Tag:0x00007f0ca900a110> #<Tag:0x00007f0ca9009fd0> #<Tag:0x00007f0ca9009e90> #<Tag:0x00007f0ca9009d50>


Every plug costs a bug

Small form-factor PCs can be versatile onsite Pen-testing devices; if they run something like Linux.

A little system, which runs… you know…

  • ettercap - for Layer 3 interception and resource manipulation
  • Yersina - Layer 2 attacks, in case of certain misconfigurations.
    • Or for NAC bypasses.
  • p0f - for passive information gathering and system fingerprinting
  • OpenSSH - for tunnels over covert network channels and commandline-access
  • and of course aircrack, and other Wireless pen-test tools

Some of these small devices have limitations, for example due to WiFi drivers. Or due to bad Ethernet chips.

Every plug costs money. So in order to prevent you from being at a large security conference, and buying the wrong stuff, you only need to read this short blog article.
Because nothing is worse, than being a n00b in the line. Like so many others… :slight_smile:

Is a PWN plug enough for a pawn?

So, why is there Chinese candy. Isn’t that suspicious?! A weird picture on the internet… help!

The PWN plug (R3) is larger than my hand, but I am not a construction worker. Today.

Here is the “data sheet”. And below is some extra information.

  • it runs Linux (Kali like)
  • has 1 Ethernet port
  • 3 USB (plus 1 USB <-> Ethernet adapter). You use the USB Ethernet to attach the target system for interception
  • 2 HDMI ports
  • WiFi for Wireless pentests (antenna, chips, driver support)

So far so good.

  • 1,1 Ghz Intel Celeron (!)
  • 2 GB RAM (!)
  • 32 GB SSD (!)

It’s sold by PWNie Express. I sent an inquiry about one small question related to the “Covert channel” feature, and never received a reply; used my business mail address. - Bought it anyways since I can guess these things. But you know what that means. You are your own expert.

Then I sent another inquiry because the repositories were down for 4-5 days. The PWNplugs run something like Kali Linux. But they use custom repos. These are sometimes not available:

Err:9 kali-rolling/main amd64 fonts-liberation all 1:1.07.4-2
  503  Service Unavailable: Back-end server is at capacity

I got a reply within minutes, and that was due to an upgrade.

2 things regarding the HW: the Intel CPU is slower than you might think, and the device is bigger and heavier than it looks. You might want the R3.

  • When you run ettercap, don’t get greedy. This device is easy to find, even without Chinese candy next to it. And it’s not fast enough to handle 1 Gbps of routing traffic; depending on the amount of clients and packets per second. This is not a Cisco Catalyst. This is a Minibüx.

Let’s open the black box and take a look.

If you want to lift the mainboard to see the SSD you need to be careful. So for warranty reasons I did not do that… But you can see that there is no fan. And no black magic. And it really isn’t a Cisco Catalyst… No kidding!

Covert channel setups: from Kali to Kali, from AWS in-reverse to the PWNplug

This is a 1 minute and 4 click setup. Yes… covert channels, these super useful data exfiltration techniques… 1 minute. Red team’s dream came true: just get this plug, plug it in, and enjoy the coffee while the Blue Team has to run through the building and crawl through the dusty corners behind the printers, where the managers are having a chat about their day-trading portfolio. Great!

From the PWNplug web UI you download a Shell script, copy it to an AWS EC2 Kali Linux, run it, and then you enable the shells via the buttons:

  • SSH via HTTP(S)
  • SSH via DNS, ICMP
  • SSH via Egress Buster (some ports)
  • or SSH via UMTS / GSM (SMS -> Bash command channel!)

You setup these shells, and the PWNplug becomes a pivoting device, just like a hacked printer or some infected IoT aquarium… or some user’s client… which covertly can tunnel out data.

I usually use a Kali Linux in AWS EC2 as the cloud endpoint, which the PWNplug can connect to. - Regardless of where I put it. No one blocks AWS IP ranges.

But this requires you to setup an AWS Security Group. And that’s no biggie:

Make sure to set the allowed source IPs to something else in reality. Because security :wink: But then just SSH into the EC2 Kali Linux and SSH into the reverse shell:

[email protected]:~$ ssh -p 3339 [email protected]
[email protected]'s password:
Last login: Fri Jul  7 13:49:19 2017 from ::1

Example setup:

These Reverse Shells are setup on the PWNplug Web UI:

These have connected to the AWS EC2:

[email protected]:~$ sudo netstat -lntup4 | grep 'pwn' | grep 333
tcp        0      0*               LISTEN      30693/sshd: pwnie
tcp        0      0*               LISTEN      31296/sshd: pwnie
tcp        0      0*               LISTEN      31098/sshd: pwnie
  • 3333 - standard SSH
  • 3334 - Egress Buster
  • 3339 - ICMP

DNS and HTTPS did not work here, bummer. Or no… good points for the defense team. - Probably a web proxy and a firewall rule. And nobody monitors the deny logs.

UMTS wasn’t used. Because I didn’t want to. There is a SMS-to-Bash trick, mentioned in the manual. If that’s in scope, it’s a fair bet that this works. And that setting this up is worth the effort. It’s a very impressive demonstration if you send an SMS, and influence the client’s network that way. Like: “May I just cook the fish in your IoT aquarium? No… oh… I… damn… what was the number again to call off the cron job.”.

Anyways, our next setup thing is “multi-hop proxy chaining”; or how ever you want to call it. All via SSH. I use Bitvise SSH & Proxifier (WinDOS), but you can use ssh & proxychains on Linux the same way.

Proxy-chaining in Windows with some xtra

Connect via Bitvise SSH (alias Tunnelier) to the Kali Linux on AWS EC2 directly, and setup a local Socks 5 proxy:

The Socks stuff is in “Services”.

Ok… that’s number 1. Now for number 2:

Connect to localhost:3339 using number 1 as a Socks 5 proxy. And open up a second Socks 5 proxy:

And for the second Socks 5:

Good. Pro tip: you can bind the Socks 5 to an IP interface. On Linux you’d use a reachable Socks 5 like this:

export http_proxy="socks5://"
export https_proxy="socks5://" here is the IP with the reachable Socks 5 proxy.

Again, what does this do? - You get 2 Socks proxies on your local Windows machine via Bitvise SSH:

  • Number 1 - traffic goes our via the AWS EC2 Kali Linux.
  • Number 2 - traffic goes from the EC2 Kali Linux to the PWNplug via an ICMP reverse tunnel, which encapsulates SSH traffic. DNS is resolved remotely!

In this example on the Windows machine: localhost:5010 (or is the proxy, that will forward you to pivot into the remote internal network via the Kali Linux hop in AWS, that listens for reverse shells.

This is easy to detect! But fear not, fellow Pen-testers. You can use the other PWNplug reverse shell listeners, which means that instead of ICMP you can use one of the other 3 protocols; or abuse.
You can even rotate… Even if you establish a Websocket reverse shell or an HTTP Proxy bridge, the principle is the same. Just add another localhost:XXXX

In order to use the localhost:5010 Pivot Socks 5 proxy, that hops via AWS into the internal network via the PWNplug gateway, you can use Proxifier.

What you see here is a bit trickier than the usual pivoting: the PWNplug is somewhere, where is used. Only for IPs within that network the Pivot Socks 5 tunnel is used.

Proxifier allows you to setup rules like that, via wildcards. These can be application specific: here it affected only Royal TS and ssh.

Royal TS (used here) is some admin tool which supports RDP, SSH etc. (and individual proxy profiles, which do not use here) and ssh.* is ssh.exe. Works without ProxyCommands in this case. Looks better.

Now that is pretty decent… isn’t it?

Trick questions:

  • What is the source IP, which shows up when I login via this SSH multi-hop tunnel?
    • Correct… the one of the PWNplug.
  • Where is the PWNplug?
    • Let’s say behind the printers (because many companies use Cloud-connected printers…), because we just stole the printer’s IP. How we steal that IP?! Next section. One command.
  • Does that mean no one can print if we do this?
    • Nope… that’s the magic of the PWNplug. Men In The Middle. Or Plug In the Middle. Or both. Men and machine! Printing will work. You can print funny things for the Blue Team, to help them.


  • we have established direct access via a local proxy listener, that will use covert channels to pivot us into a remote network.
  • we used some nice Windows tools to setup rules for the proxification. Basic Pivoting Kung Fu.
    • The shown example is an ICMP reverse-Shell backdoor channel, like Malware or data-thieves can use it. It’s possible to do the same with a Linux client, using proxychains. That’s up to you.
  • You can do all of this with an even smaller system, and nothing of this is exclusive to the PWNplug. The setup with it however is extremely convenient, and saves a lot of time. And the Ethernet MITM actions might require some performance.
  • Do any security tools detect these protocol encapsulation channels? IDS / IPS? DLP? Proxy? Firewall? SIEM? Hello blue-team? You think that’s the printer? For real?

Once the reverse shells and the tunneling setup works, it’s time for Men In The Middle attacks.

Men-In-The-Middle - printers print, PWNplugs pivot, easy to do

So let’s steal the printer IP, and become a transparent interceptor that abuses the network. Printers often have a lot of network access, and many clients connect to it… awesome.

802.1X / NAC bypass techniques aren’t too easy to do. Unless you have a PWNplug. There is also a smaller one, which is harder to find than the R3.

Check out the manual - page 29. Plug the printer in, at the USB-Ethernet port adapter, and fire up the command. Reboot and enjoy.

Result: too much trust in NAC systems is not justified. It can prevent some unauthorized access, but without monitoring and security-controls a NAC is not efficient. Same goes for firewalls. If no one monitors them, they are useless. Attacks will just poke them until they find a whole to abuse. And with printers this is easy.

Field-smart PWNplug - HackRF covert channel for WiFi IDS evasion

The term Field-Smart Radios is from the origins of Software Defined Radio (SDR). Essentially an SDR is a generic sending and transmission device, that allows you define custom communication systems in software.

The HackRF is a portable small SDR hardware, a transceiver actually. It can send within a wide range of frequencies. You can use it with GNU Radio, and send or receive data. A Wireless IDS, that detects rogue WiFi access points, the one in your PCI-DSS environment, can probably not find a HackRF. Air-gaps can be bridged.

Something like this would only make sense for certain environments, obviously. There are cheaper options. Like using an Ubertooth or a Goodfet (these are documented in the PWNloug manual). Or… if you can use a UMTS stick… chances are good that this is cheaper and more reliable. So for UMTS, IEEE 802.15.4, IEEE 802.15.1… for common wireless standards use a common dongle.

For a HackRF channel you may need to be nearby; at least for the scenarios I have in mind. I don’t think anyone would be stealthy enough with a large amplifier, a HackRF and a PWNplug next to a printer. Although… I mean… try it out.

Personally I have used OFDM for that, but getting 2 SDRs to create a wireless TCP/IP connection is not new. It just works, and you can adjust the frequency etc. if you change the parameters of your flow graph.

Gumstix - is an ARM armed enough?

Some printers have USB ports. and Gumstix Single Board computers are much smaller than a PWNplug.

You might want to try a Raspberry Pi? Or a Beagleboard. If you can use a 20 USD device, and chances are good that you will be able to outsmart a 500 000 Euro security system, that is impressive.
Test it in the lab, put some firewalls, IDS / IPS, DLP etc. in between. And see what you can do. What could possibly go wrong…

So why did I mention the PWNplug at all?

  • Because it takes less time to setup a PWNplug. You can just port the reverse-shell connect commands over. Start with something that is known to work. Learn to walk before you are trying to run.

What's the cure? A better IDS?

An IDS which doesn't detect ICMP backdoors is...

h hard to find. True that, as I said. The relevant Emerging Threats signature is ET INFO PTUNNEL INBOUND / OUTBOUND.

The blue-team should see that, find the IP, and block it. Even an OpenSource IDS detects this. I am fairly certain your Common Off The Shelf NIDS has something similar. Go, test it. It needs to detect DNS encapsulation, ICMP reverse shells, Web shells.

Trust but verify

Exercises like this are necessary to shape focus. You can either fine-tune your IDS to detect less XSS noise, or tune it to detect potential backdoor communication. Your call.

The cure is to test security stacks. Can you rely on your’s? No. Of course not. Can you use it… Not sure?

Linux Without Borders, Edition 1 (Nov 2017): network-ergonomics and cloud-mounts for the impatient