SANS Penetration Testing

This is the Winter2012 of our Discontent: Guessing Bad Rotating Passwords

[Editor's Note: Sometimes the most effective and lethal penetration testing and ethical hacking techniques are shockingly straight-forward. Tim Medin offers hugely useful advice in this article on fine-tuning your wordlists based on the target organization's password policy. Read it and live it — these techniques will make your password guessing attacks much more effective. -Ed.]

When walking into a client, I like to have a number of attacks ready to rock while I let the (usually obligatory) Nmap and/or Nessus scans run. This gives me something interesting to do while I wait for the coffee to replace the blood in my veins. Once I get that engine running and the coffee shakes start, you better stand back.

Password guessing, when done right, is one of the attacks with a high success rate. You may not get an admin account, but it is almost guaranteed that you will get at least one account as a solid foothold. To do this right you need to be mindful of the lockout threshold, the amount of time the systems remember failed attempts, and the password complexity requirements. But, one of the most useful bits of information to have when guessing passwords is the rotation frequency.

You may be wondering, "How in the world would it help to know the password rotation frequency?" Well, the short answer is, the more often passwords must be changed, the greater the likelihood users will use a formula to derive the passwords. We pen testers can use this frequency to our advantage.

If users have to change their passwords every quarter and they can't reuse a password for six years (remembering the previous 25 passwords is common, so 25 / 4 = 6.25). Coming up with 25 good, unique passwords is hard, so many users will derive their password from their surroundings. A user thinks to himself, "I have to change my password this quarter, what else changes every quarter?" The answer, the season; and the season+year will never repeat.

Given it is currently November, good guesses are Autumn2012, Fall2012, or Autumn12 (Fall12 is probably too short to be allowed but don't rule it out). Some users will still have their password from the summer, so Summer2012 or Summer12 are viable options; as are Winter2012 and Winter12 for users who recently change their password.

If the rotation policy is every 30 days then likely candidates would be the past, current, and next month combined with the year, such as, October2012, October12, November2012, November12, December2012 and December12. These passwords meet the typical complexity requirements that require three of the four sets of character types (upper case, lower case, number, and special character). Users will usually skip the special character if they can. If the organization requires four of the four classes, just append ! to the end of the password.

Of course, don't discount the serialized passwords using base words followed by a sequential numbers that increment each rotation period (e.g. baseword20, baseword21, baseword22). Common base words are the company name (CounterHack10) and local sports teams (Pirates12). You could try every team, but the local teams are usually good for at least one correct hit.

These rotation policies are put in place to limit the amount of time that compromised credentials can be used in an environment or to (hopefully) rotate the password before the password can be cracked. However, cracking the password doesn't matter in the Windows world as pass-the-hash and tools like mimikatz remove the requirement to crack the password. As for the limiting the time a compromised credential can be used, how long would it take for an attacker to extract all the sensitive data from your environment using valid credentials? Days, hours, maybe even minutes? My tests are usually a week (or two) long and I can get all the data I need in that amount of time.

To perform automated password guessing we can use a tool like medusa. To do this we need to create list of possible usernames and passwords (two files). The password file we generate from our guesses above, BUT do NOT meet or exceed the lockout threshold or you could cause a widespread lockout and an RGE (Résumé Generating Event). I usually use n-2 where n is the lockout threshold.

Prior to arriving on-site, you can use tools to extract usernames from publicly available sources. I like the Recond-NG (http://ptscripts.googlecode.com/svn/trunk/recon-ng.py)> tool by Tim Tomes (aka LaNMaSteR53), which finds employee names and uses those names to generate possible usernames. Once we have our two files, we can use medusa like this:

medusa -h targetipaddress -U UsersFile.txt -P PasswordGuessesFile.txt -M smbnt -m GROUP_OTHER:MyDomain

The command above we use -U to specify a file containing usernames and -P to specify our password file. The -M specifies the authentication mechanism (SMB) and the "-m GROUP_OTHER" is used to specify the Windows Domain. Now, to select the system to authenticate against.

On internal tests I like to find a file server, as most users can authenticate against it as it will give me useful information once I get a hit. The web-form module works well on perimeter tests when SharePoint or Outlook Web Access is available.

Depending on the target system and the number of users and passwords I'm trying I usually get at least one hit within an hour. Now, how do you as a defender prevent this?

The big issue here is that the and passwords are allowed and considered "complex." I'm a big proponent of longer, more complex passwords and changing them less often. In the Microsoft's paper "So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users" (http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNoThanks.pdf) it says "users have decided that the cost [of rotating complex passwords] is far too great for the benefit offered. If we want a different outcome we have to offer a better tradeoff." The solution put forth is to increase the complexity and length requirements but let the users keep the password longer (year).

Happy Autumn2012!


Tim Medin | tim@counterhack.com

[Special Announcement: SANS Security 560 in SMELL-O-VISION!

Ed Skoudis and I will be co-teaching the SANS Security 560 Course using SANS across-the-Internet training platform, vLive in January and February 2013. Register by November 28 and get a free MacBook Air or Ultrabook. Details of the special offer are available here: http://www.sans.org/vlive/specials

To take advantage of this offer, enter one of the following discount codes at checkout:
1108_MAC (MacBook Air)
1108_TOSH (Toshiba Portege Ultrabook)
1108_850 ($850 Discount)

So, what's SMELL-O-VISION? Keep reading, please.

The class will be offered via the Internet over a 6-week span
using SANS' vLive infrastructure, giving you plenty of time to study,
review, and master the skills and numerous hands-on labs. Classes begin
on January 7 and will meet on Monday and Wednesday nights.
Full details can be found at http://www.sans.org/info/116182.

Regardless of whether your job is penetration testing, security
operations, system administration, incident handling, or another security
area, this course will show you how you and your organization can get the
most value out of penetration testing, with in-depth technical excellence
and business smarts.

And, yes, there will be Smell-O-Vision. How? In your registration
package, you'll receive detailed books, course exercises, and a course DVD
for all of the hands-on labs, which include access to a target environment
across the Internet through a VPN. But you'll also get a special
scratch-n-sniff scent kit which Ed and I will seamlessly integrate into
the lectures, indicating the proper time to smell each item to help hammer
your memory receptors with knowledge of given skills.

Yes, this is going to be a special event indeed.

We hope you'll be able to join us! For more information, please visit
http://www.sans.org/info/116182. Register soon, because Smell-O-Vision
will be arriving right after the holidays!]

2 Comments

Posted December 4, 2012 at 11:41 PM | Permalink | Reply

Bruce Marshall

One important note for any pen tester or security personnel: don't use tools like medusa for active password guessing if the Windows environment has an account lockout policy. You will quickly make enemies in the help desk group and elsewhere in the company.
Otherwise, I like the advice to teach your users to go long on the passwords. But you'll still have to keep an eye out for "IDon'tLikeTheWinter12".

Posted December 25, 2012 at 9:26 PM | Permalink | Reply

Robin Wood

The link to the MS paper has a ) at the end of it so links to a 404.
An accident I had on a test that is worth mentioning is that I avoided doing a brute force against SMB as I knew the client had a lockout policy of 3 fails but I decided to try against ssh as I've never seen ssh on a Linux box with a lockout policy. Turns out one of the machines I tested was backed off against active directory so I ended up locking accounts out anyway.

Post a Comment






Captcha


* Indicates a required field.