PTJ Undermines Your Blinky Light Box

So, you just bought that fancy new box with the blinky lights that's supposed to somehow keep you safe from the bad guys. While it is true that some of these machines run on unicorn blood and fairy dust, they still don't keep you safe from stupidity, or even worse – laziness.

Below are true stories of how I went from basic network access to domain admin without exploits, effort, or a care in the world. Each one of these scenarios took place in fairly large organizations that felt my PenTest attempts would be futile due to their "enhanced security" (I always giggle when people say that).

PTJ pwns the Pretty Pony Palace

In this situation I had scanned a subnet to see what kind of services were listening. I found several FTP servers. One of them allowed anonymous read access, so I decided to connect to it to see if it had any files. It did, one juicy, delicious text file:

You see  that? "asdf.txt" ? That innocent and unassuming looking file contained some plaintext storage of passwords. Oh, and that "d_t_a" account? That was the "Domain Test Account" used for testing various applications and environment changes – It was a domain administrator. It was pretty much game over at that point, I logged into the DC, dumped hashes, and proceeded to look for CHD.

Who on earth would think putting plaintext passwords in an anonymous FTP share would be a good idea? Scumbag Sysadmin did.

Scumbag Sysadmin: "I'm sick of remembering these retarded passwords, they're test accounts for god's sake! I'll just put them in a text file real quick on an FTP server while I work on this project. Its no biggie, I'll take it all down once I finish"

Scumbag Sysadmin: *NEVER TAKES IT DOWN*

PTJ pwns the Prissy Panda Park

In this situation, while looking through my NMAP output I noticed a host had(among other ports) VNC open. So I decided I'd connect to it and see if anything useful shows up. My internal thought process went something like this:

1. Oh lookey at that, there is no password for vnc, how welcoming of them.
2. A redhat machine? Interesting, lets take a look around, lets start with bash_history.
3. Yeah, yeah, yeah, bunch of editing files, and a bunch of…wait, is that…yes it is!
4. Looks like someone connected to a mysql box and typed the password as an argument for the command!
5. 
6. I wonder if those credentials work on that one ms-sql box...
7. Oh you, you are just too kind to me.
8. My magic pentest 8-ball predicts "xpcmdshell is in your future"

The magic PenTest 8-ball was correct, as it always is. Once I got access to the mssql box, I impersonated a domain admin's token, and continued the fun. Moral of the story here? Put strong authentication on points of access, and avoid typing your password as an argument.

The important thing to remember here is that these are not made up scenarios, these ACTUALLY HAPPENED*. These organizations were not some small shops with no IT guy, these were massive, you've-definitely-heard-of-them shops. So, before you decide to scoff and say "oh, that could never happen to me, those are special cases" – they really aren't. Things like this happen way more than they should.

Here are some lessons to take away:

1. Never assume you can't be hacked or that you are safe from a particular attack. Never assume anything, you must test, verify, and test again.
2. If your bosses have a stigma to the idea of "hacking the company for defense" than don't call it hacking. Call it something like "Enhanced Active Defense" or something that sounds like a marketing team came up with.
3. An attack vector is an attack vector, whether or not it's a flashy new 0-day.

*Pandas were maintained at a safe location for the duration of the testing.