How to Pen Test Against Orphaned and Privileged Accounts

The more pen-tests I do, the more I see that despite how every organization claims that they’re different, I see the same commonalities with how things are being managed inside the network. One of those commonalities that I see tends to vastly improve my odds of persistence and avoiding detection: how an organization handles orphaned accounts and service accounts.

Let’s talk about a little theory of why we force password changes on a regular schedule. This is beginner material, so feel free to skip to the good parts at the end. In most systems and applications, passwords are never stored “in the clear” or using a reversible encryption. They are stored in a hashed format for a couple of reasons. One reason is that passwords are supposed to uniquely identify a user (although in reality all I can testify to is that someone used a particular users password), and as such, the administrators and operators should never know a user’s password. The biggest reason is to act as a barrier to attackers once they obtain the hashed versions of the passwords, and limiting the time horizon when these passwords are still valid if they are cracked. Obtaining these password hashes can be a trivial exercise. There are a variety of attacks that don’t even require popping a domain controller to be successful.

Where to get password hashes

There are a couple of ways that I like to grab password hashes. Obviously, the gold standard is to be able to pop the domain controller and extract the hashes that way, or to stumble across a backup image of a domain controller. If you can get a toehold via a phishing attack or USB drop using Core Impact, you can run our WPAD - DHCP Responder module to spoof other local machines into providing their current credentials. I also like cross checking the password leak lists for corporate accounts. You’d be shocked at the number of times I crack a password in the first pass because it was in the 2012 LinkedIn breach. Four out of the last five pen-tests I did featured domain admins with passwords that were in the LinkedIn Breach.

We’ve got hashes, now what?

So now that we’ve got hashes, now we need to crack them. Dictionary attacks with common mutations are very effective, but exhaustive brute force attacks are faster ever than before. How fast? With a pair of GTX 1070 video cards, I can push about 30 BILLION NTLM hashes per second. The GTX 1080 cards are about 30% faster.

Considering the potential characters, we have 26 lower case letters, 26 upper case letters, 10 digits, and 33 symbols on a standard keyboard, or 95 possible characters. For an 8 character long password, we have 95 X 95 X 95 X 95 X 95 X 95 X 95 X 95. Which is a lot. I ran out of fingers. Okay, it’s 6,634,204,312,890,620. That’s six quadrillion, six hundred thirty four trillion, two hundred and four billion, three hundred and twelve million, eight hundred ninety thousand six hundred twenty possible passwords. With the dual GTX 1070 rig above, that will take me no more than 221,141 seconds to crack every single possible password. Just a smidge over 2.5 days.

Reality check

Obviously, we want user passwords to be changed regularly, so that when an attacker gets the password list, they won’t be able to use them for very long. Now, if you increase the minimum password requirement to 10 characters, the crack time to exhaust the keyspace is 63 years. So there’s that. Two factors (sorry, bad identity pun) that will come into play are the fact that human brains are horrible at remembering things much longer than 8-9 characters. This is why local phone numbers in most parts of the world are shorter than that.  When you either lengthen the passwords, or shorten the rotation period, you end up with big problems. Problems like help desk calls, which are very expensive, and grow exponentially more expensive the more systems the help desk has to touch to reset passwords. Do yourself a favor and take a look at Core Password and Core Provisioning to make it less of a headache to maintain a reasonably secure password policy, and to take care of those orphaned accounts that belonged to people who left the company five years ago and were never disabled.

The other side of the coin

I love cracking service accounts. The reason is that they are rarely randomly generated, and they are almost ALWAYS exempt from the standard rotation policy. Why? Because nobody wants to break a business critical service when they forget to update the credential everywhere. This gives me plenty of time to crack the account, and use it to build long term persistence. Wouldn’t it be great if you had a tool that not only helped you manage those service account dependencies, but it allowed you to rotate them at a click of a button if something felt “off.” You deserve to have a privilege account management tool in your enterprise, since life’s too short to worry about bad credentials.

Do you have other password questions? OR are you worried that your employee’s passwords are only 2.5 days away from a breach?