Last Thursday, John Strand and I delivered a new webcast on post exploitation, covering all kinds of tips and tricks. I focussed on some of the cool stuff you can do with the Windows netsh command, including setting up port pivots, sniffing, and gaining remote access to a target's network configuration. John Strand discussed a new tool his team released that provides a command and control channel via gmail. We covered a lot of fun and useful material.
The slides are available here.
And, if you'd like to hear the webcast itself, you can do so
[Editor's note: Josh Wright spins up another useful blog article about different ways to move files to and from Linux systems. Lots of nice little tricks in this one. Thanks, Josh! --Ed.]
By Josh Wright
Sometimes I find myself with access to a remote Linux or Unix box, with limited opportunity to transfer files to my target. I appreciate the "Living off the Land" mentality and relying on locally-available resources instead of adding tools to my host as much as the next guy (or gal), but sometimes I need a binary to get the job done.
Fortunately, I've been working with Unix and Linux for a long time, and I remember old techniques back when modems made that horrible screeching sound. As long as you have a terminal, you can upload and download files regardless of other network accesswith a little awkwardness.
Encode and Clip
In the example that follows, ...
By Ed Skoudis and Josh Wright
Josh Wright and I were working on a project recently which involved a target machine with a really restricted shell environment. I'm not talking about a mere rbash with some limits on the executables we could access, but instead a shell so restricted we could not run any binaries at all, save for the shell itself. No ls no cat no netcat we could access very little. It was some sort of ghastly chroot specter.
Still, Josh and I wanted to explore the target machine as much as we could given these shell restrictions. Of course we could have tried escaping our restricted shell (as Doug Stilwell describes in more detail here) and even doing privilege escalation, but before that, we wanted to just look around. Thankfully, we had many shell built-in capabilities we could rely on.
For the uninitiated, shell built-ins are
Here's some fun news. SANS just released a new kind of challenge — one that unfolds from the pages of a SANS brochure itself. Created by Jeff McJunkin and a group of challenge-writing collaborators, we launched it this week with the mailing of the SANS Network Security brochure for the upcoming conference in Las Vegas in October 2014. This challenge will take you across many domains of knowledge, including (but not limited to!): infosec fundamentals, pen testing, digital forensics, steganography, social media, mobile devices, and much, much more, all wrapped up in some geeky fun!
You'll enjoy all these areas and more from the comfort of your brochure (paper or pdf) and local computer, along with everyone's favorite global network, the Internet itself. You'll be able to advance all the way through this challenge from anywhere in the world. If
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